Hi Michael, Actually after the emails you previously exchanged with Alex I expected such a request would eventually come. You would like to control all the Styles Filter functionality from the plugin instead of instructing the user to modify each document type individually. This is the first request so far because developers are usually interested in a certain document type (extending it, modifying it) but you want to offer your plugin as a solution no matter what type of XML document is edited. And of course the styles filter you implemented would need to be an addition (and not a replacement) of the current styles filter. I registered this as an improvement request. One problem I see is that the StylesFilter needs to be available very early (when the XML document is loaded) but the plugins API allows you access to the document after it has been loaded. So if such an "addStylesFilter" API would exist, it would need to trigger a complete refresh of the loaded document because it would affect the way in which the loaded document looks like. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 12/31/2012 1:22 PM, Michael Anthony Smith wrote:
Hello,
Is there a way of adding StylesFilter object to an arbitrary framework via the API, rather than having to manually configure it for each framework independently?
If there is not a mechanism for adding StylesFilter object's already, possibly it could be added to the 'ExtensionBundle API class'; here the idea is that a third-party plugin/extension could add a StylesFilter to a 'styles filter chain' that is maintained by an extension bundle API. Alternatively, it might be appropriate to add this 'styles filter chain' idea to to one of the Editor[Page] API classes.
The context for this query/request is included as a postscript to this email; this discusses how we have currently managed to get our StylesFilter to be used. If it were possible to add a StylesFilter to an arbitrary document through the 'WorkspacePlugin' API, I believe our 'merge conflict resolver' extension could be provided as an oXygen plugin (without the need for any user configuration of the oXygen preferences).
Best regards, Anthony. * * *PS: *I am involved in a development of an oXygen extension/plugin that enables 'conflict resolving of merged documents'. Thanks to your previous help we are now able to highlight the 'merge updates/conflicts' between two processing instructions, enable them the available options to be selected, and the currently selected option to be edited. We still have to add some functionality such as 'the ability to accept currently selected content', but this should be straightforward (given what we have already got working).
Currently we are using a mixture of oXygen's Author and Plugin SDK APIs, and a manual configuration of the 'document type association' in order to add our 'merge conflict' styling. The following screenshot shows how we are manually updating the DITA 'document type' to add this styling.
-- -- ------------------------------------------------------------------------- Michael Anthony Smith, DeltaXML Ltd "Michael Anthony Smith, DeltaXML Ltd "Experts in Information Change"" T: +44 1684 869035 E: anthony.smith@deltaxml.com <mailto:anthony.smith@deltaxml.com> http://www.deltaxml.com <http://www.deltaxml.com/> Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
_______________________________________________ oXygen-sdk mailing list oXygen-sdk@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk