Home › Forums › DITA and XMetaL Discussion › How to configure XMetaL so that unsupported elements are hidden › Reply To: How to configure XMetaL so that unsupported elements are hidden
Reply to: How to configure XMetaL so that unsupported elements are hiddenFebruary 14, 2014 at 7:17 pm
Recommended and Supported:
You should create a specialized DITA DTD that does not define the elements you want to stop your users from using, then configure XMetaL Author Enterprise to use that specialized DTD (see Help topic: Working with DITA > DITA Specializations). This is the supported solution for what you are asking for, it is clearly defined by the DITA specs, supported by most DITA authoring tools (so you have flexibility if you wish to use other tools), and is supported by the DITA Open Toolkit.
The Alternative; Not Recommended, Not Supported:
In theory this could be done using script but any scripts you create would need to “play nicely” with the scripts that drive the DITA authoring functionality. JustSystems does not support altering the DITA authoring functionality in this way (so you would be on your own, and future releases of XMetaL Author Enterprise may require you to rewrite any changes you have made).
To cover all possibilities this would be a very difficult task as you would need to do something like the following:
1. Remove elements from the Element List. There are APIs for this. This is simple enough to do.
2. Intercept all pastes and block them when they contain elements you do not want in the document. There are APIs for this, but as the DITA authoring functionality already intercepts pasted content to implement several features it would be difficult to write code that works and does not break these other features.
3. Remove all or portions of the DITA-specific Insert menu.
4. Remove items from any toolbars that allow for the insertion of elements you want to block.
5. Stop users from switching to Plain Text view. Users can do anything they want in this view, and if their document is valid according to the DTD, then they are free to save without errors being displayed and they can switch back to Tags On or Normal view. There is an API for this.
6. As a final check, perform additional “business rules” checking when documents are validated. I would recommend doing this as some of the other previous things implemented above might not catch everything unless your code is really robust (particularly #2). Normal validation would occur and then your script would walk the entire document for certain elements and tell users they would need to remove them before saving (or whatever you choose to implement). There are APIs for this, including some that let you inject your own messages into the Validation Log. How much work this will be will depend on your requirements for how this should function. This additional “business rule” check would also slow down the validation process, which means that saving would also take longer.
There is currently no way to limit, extend or alter what appears in the “In-place, look-ahead element list” (Ctrl+Enter) using APIs (ie: no equivalent of the On_Update_ElementList event).