[schwamkrug]

Thanks, Derek. I'll look those over for ideas. To give some background, the reason I'm looking into this is because we have some cases where users have to type in values (as opposed to selecting from a list) for several attributes. Most of the time, the attribute inspector is great. Attributes usually aren't modified, so they're hidden until they're needed. But when there are a lot of attributes to modify, using the attribute inspector isn't ideal… it's just a lot of switching back and forth between placing your cursor in the right spot in the document, then switching to the attribute inspector to find the attribute and enter/modify its value. Some people try switching to plain-text view, but become frustrated with that for other reasons.

Reply

[schwamkrug]

I see. Thanks for the info. Does this thread serve well enough as a request to make this configurable in a future release? Ideally, we'd be able to provide which attributes we want in that dialog and also be able to override that on an element-by-element basis.

Is this something I could hack myself if I dug around in the Javascript code, with the understanding that it's an unsupported hack?

Reply

[schwamkrug]

I ran into a similar issue where XMetaL 6 will insert one of the OOTB topic types (concept/task/reference), even if the topicref is to a specialized topic type. From a pure DITA perspective, the @type attribute is optional, so I made a startup macro to disable @type attribute insertion altogether. I've attached my macro, in case it helps. Maybe it can be hacked to always insert the type attribute?

I think your issue might be because @type attributes, if unspecified, are inherited from the parent topicref? Given this map code:

 

I believe the inner topicref will get type=”task” added by DITA OT preprocessing, even though the inner topicref is to a concept:

 

Reply

[schwamkrug]

No, there's nothing DITA-invalid about the markup, and it's not the markup that's cumbersome. What makes it cumbersome is our CMS's conref creation UI. You have to go through multiple dialogs, each of which can be kind of slow to open. Then, you discover that you forgot to add an ID to the element you want to conref, so you have to check out that topic, add the ID, then go through the conref creation dialogs again. My macro just lets my users copy/paste a paragraph (or whatever) and get a conref instead of a plain copy/paste. It doesn't directly interoperate with the CMS. It just looks at topic/element ids at copy time to add a conref to the clipboard.

Reply

[schwamkrug]

Thanks! Worked like a charm!

Derek, I'm possibly getting too hung up on semantics here… This macro is indeed being used with DITA topics, but I'm not directly modifying the DITA authoring functionality like I was with my question about @type attribute insertion. Our CMS's functionality for creating conrefs is a bit cumbersome, so I created a macro that will let you copy/paste content as a conref, rather than a plain copy/paste. It also lets you create conref ranges if you copy a set of elements. It's deployed as a macro in the startup dir, so I suspect that macro would be available with any other doctypes, although it would almost certainly throw errors with non-DITA files.

I'd be happy to send it to you if you're interested. This macro is pretty specific to our CMS environment, but it might be useful to others with some tweaking.

-Kyle

Reply

[schwamkrug]

Update: I dug around and found the code that inserts these attributes and managed to override it with a macro in my XMetaLAuthorStartup folder:

[code]

    //Copied from the out-of-the-box implementation. Commented out some calls to XM.XML.SetAttribute();
  }
]]>

[/code]

So, a couple of follow up questions:
– Are there any ramifications to removing @type attribute insertion entirely? I see what I need to change to instead have my specialized topic type inserted. Should I do that instead?
– Are there any issues with my general approach of using a startup macro to override this functionality?

Reply

[schwamkrug]

For specialized topics the unspecialized topic type will be set.

That's the main issue I'm having. We need to do custom processing of topicref where @type is one of our specialized topic types. It would be nice, but not required, if it wasn't set at all (looking forward to when we can upgrade to 7 or 8, for lots of reasons). But it's critical that it be set to our specialized topic type, if it's set. We're going to have a lot of these, so expecting our authors to set that attribute explicitly won't be sufficient.

I'm comfortable with hacking the macros and javascript you guys provide if you can point me to the right place to look.

Thanks!
-Kyle

Reply

[schwamkrug]

Just now getting back to this… Is there any other way to invoke auto-id generation from a macro? This is in XMetaL 6.0, by the way.

Reply

[schwamkrug]

Awesome, thanks.

So, I think an easier answer just slapped me across the face:

[code]
var rng = Application.ActiveDocument.Range;
var selectionXMLString = ““+rng.Text+”“;
var xmlDoc = new ActiveXObject(“msxml2.DOMDocument”);
xmlDoc.loadXML(selectionXMLString);
var nodes = xmlDoc.documentElement.childNodes;
[/code]

Reply

[schwamkrug]

Thanks, Derek. That helps a lot.

Slight change of subject…is there a way to reload .mcr files without restarting XMetaL so I can test changes to my code?

Reply

[schwamkrug]

I guess it depends on what you mean by modifying… I'm just adding a macro to fill the clipboard with a conref. It's written as an application macro, so it's not really aware of whether it's in a DITA doc or not. It just looks for elements with id attributes.  I'm not looking to hook into or override any of the functionality you guys provide.

Reply

[schwamkrug]

Sure. I'm working on a macro to enable cutting/pasting content as a conref. It was pretty easy to do this with a single element…with the cursor inside a given element, get Selection.ContainerNode, then do typical DOM stuff to add a conref to the clipboard. But what I want to do is extend that to also do conref range. Consider the following (assume all these elements have ids):

 

Paragraph 1, with some inline elements included in them.

 

Paragraph 2

 

Paragraph 3

 

Paragraph 4

 

Paragraph 5

If the following is selected:
 

Paragraph 2

 

Paragraph 3

 

Paragraph 4

I'd use the id from Paragraph 2 for the conref attribute, and the id from paragraph 4 for the conrefend attribute.

However, if I selected this:
  inline elements includedOr this:
    some inline elements included in them.

Those would be error conditions. Those wouldn't be the only error conditions. The main thing is that I'd need to get a node list and look at it to see.

Reply

[schwamkrug]

I don't think that would help because it wouldn't give me the ability to see which specific nodes are selected. Imagine this chunk of content:

 

Paragraph 1

 

Paragraph 2

 

Paragraph 3

 

Paragraph 4

 

Paragraph 5

And assume I have paragraph 2 and paragraph 3 selected. Selection.ContainerNode returns the element. I don't see how I could use XPath to get the two specific paragraphs that are selected.

Reply

[schwamkrug]

Yep, that's what I need. Thanks!

Reply

[schwamkrug]

Ahh, I see. I got so used to doing it through the Table menu that I didn't think to try the old-fashioned way.

Thanks!

Reply

[Author]

Posts