Updating links on New and Save As

[sanGeoff]

Does anyone know the best way to update links in a DITA topic to make sure they are valid relative to where a file is? Is there anything built into oXygen that does this already such as the map manager re-factoring?

Many of our template files have conref's and links in them. They are valid relative to our template folder. But as soon as the files are used to create a new file (or untitled, unsaved file), the links will most likely be broken and need to be updated. It seems like having conref links and text in template files would be a common thing.

I tried using the isNewDocument() field but that was kind of useless because when you do an "insert > new..." in map manager, the file is saved first, therefore isNewDocument() returns false. Also a user may choose Save As on a file to create a new file in a different relative folder resulting in broken links.

The best solution I have come up with so far is to have a root attribute otherprops="newFile" on all our template files. If a file has that attribute/value on editorOpened(), update references relative to template directory and then remove the attribute/value.

[Radu]

Hi,

Besides using the API to accomplish this (and it seems you are already on the right track with it) here are a couple more ideas and suggestions:

1) Use DITA 1.2 keyrefs and conkeyrefs instead of direct links and conrefs. One great aspect about DITA 1.2 indirect addressing is the thing that the topic can be moved anywhere and its internal links will still work.

2) In a new file template you can use editor variables, unfortunately we do not have an editor variable which does what you want. But you can expand your own editor variables using our API.
So basically in the XML content of the topic you could have something like:

Code: Select all

<ph conref="${relativePathTo}/target.dita"/>

Then you could use our API:

Code: Select all

PluginWorkspaceProvider.getPluginWorkspace().getUtilAccess().addCustomEditorVariablesResolver(.....)

to add an editor variables resolver which will be called also for the content of the XML file. If the resolved detects in the string the custom editor variable pattern, it can use the location of the current file (received as a parameter) to expand the editor variable to a certain relative folder path.

Regards,
Radu

[sanGeoff]

Ah I did not even think about DITA indirect addressing, thanks for the info.

I think I have some working code now.
My code was having some issues because I was using element.setAttribute() instead of controller.setAttribute().

I'm still having some trouble handling when files are saved.
Is it at all possible to get the editor location before and after a save and update any links (xrefs, conrefs, images, hrefs)?

- Don't know the new name yet in editorAboutToBeSavedVeto().
- editorSaved() is to late, unless I save the file again after updating links.
- No way to even get the current or new file name reliably.
getCurrentEditorAccess() may not be correct if someone is saving multiple files at once.

Thanks,

[Radu]

Hi,

Please see some comments below:

My code was having some issues because I was using element.setAttribute() instead of controller.setAttribute().

Indeed, you must always use the controller to make modifications when the elements are in the live edited XML document. In this way you will have undo/redo support and the application will properly get updated to reflect the changes.

Is it at all possible to get the editor location before and after a save and update any links (xrefs, conrefs, images, hrefs)?
- Don't know the new name yet in editorAboutToBeSavedVeto().

Indeed, this is a callback which would allow you to reject the save procedure and do your own, but it is called to early to help with your case.

- editorSaved() is to late, unless I save the file again after updating links.

Yes, you can use the WSEditor.save() API to save again the file after making the changes to it.

- No way to even get the current or new file name reliably.
getCurrentEditorAccess() may not be correct if someone is saving multiple files at once.

When creating new documents using the File->New action the documents are first opened as untitled and then the user will manually save them to a certain location. In such cases you get a callback that a new editor was opened and on that new WSEditor you can add a WSEditorListener which will receive events when the user decides to save the document. The WSEditor.getEditorLocation() method can be used to query the editor URL.

But when you create new topics directly from the DITA Maps Manager (or from the Project view contextual menu actions), the user will pick a place where to save the document without first opening the document in an untitled phase. So you will only get notified when the document is opened but the document contents is already saved at that particular location the user chose.

So to summarize this:

1) Either use indirect addressing.
2) Or set that @otherprops attribute to mark new topics, then when any topic is opened you can look if it has the attribute, if it does, you would need to operate the changes. The problem would be that you would not know the original place where the template was stored in order to re-build the relative references but your project probably has a certain fixed structure where the templates are kept so in particular this can be done.
3) Use a custom editor variable as I advised you. This would work well for the case in which the topic is created directly in the DITA Maps Manager because the editor variable will be expanded knowing the place where the content is saved. But it would not work when you create a file using the File->New action because that creates an untitled document. But you could advice your users to always create the file using the DITA Maps Manager actions.
4) You can also use your own mechanism to create these special templates. For example you can add a button to the toolbar called Create special templates and you would control the entire process, then open the document in the editor after you have computed its content.

Regards,
Radu