Disable default implementation of ClipboardFragmentInformation

[ralfpeterkorte]

I'm working on a Copy/Cut + Paste feature and have to get rid of the default implementation of ClipboardFragmentInformation
because it removes the id attribute when pasting into same document. I need the id attribute information in my own implementation of ClipboardFragmentInformation.

The default implementation of ClipboardFragmentInformation seems ot be ro.sync.ecss.extensions.commons.id.DefaultUniqueAttributesRecognizer.

How can I programmatically remove / disable it? Any suggestions? Thanks.

[Radu]

Hi,
What kind of XML documents are you editing?
Are you adding your fragment processor from an Oxygen plugin or from a DITA framework customization?

Regards,
Radu

[ralfpeterkorte]

Hi,
I'm editing DITA documents. Here is the way how I add my own FragmentProcessor

AuthorDocumentController controller = authorPage.getDocumentController();
MyClipboardFragmentProcessor myClipboardFragmentProcessor = new MyClipboardFragmentProcessor();
controller.addClipboardFragmentProcessor(myClipboardFragmentProcessor);

[Radu]

Hi,
I need more context, did you create an Oxygen plugin which does that or did you extend the "ro.sync.ecss.extensions.dita.DITAExtensionsBundle" in a framework extension folder?
Regards,
Radu

[ralfpeterkorte]

Hi Radu,
thanks for your feedback. It's an Oxygen plugin.
regards,
Ralf Peter

[Radu]

Hi Ralf,

The default implementation of the clipboard processor is in the DITA framework configuration folder (OXYGEN_INSTAL_DIR/frameworks/dita).
So if for example you go to the Oxygen Preferences->"Document Type Association" page and edit the "DITA" framework extension, it has a "Classpath" tab in which there is a reference to a "dita.jar" and an Extensions tab where there is a reference to a "ro.sync.ecss.extensions.dita.DITAExtensionsBundle".
This DITAExtensionsBundle has a default implementation of the clipboard fragment processor:
https://www.oxygenxml.com/InstData/Edit ... rocessor()

So from a plugin's code you may add your own processor, but it gets called to process the fragment after the "DITAExtensionsBundle.html#getClipboardFragmentProcessor()" is called, meaning that just from the plugin you cannot force disable the extension code in the DITA framework.

One can create their own "DITA" framework extension folder outside of the Oxygen installation folder:
https://blog.oxygenxml.com/topics/autho ... aring.html
Your extension of the "DITA" framework can add in the "Classpath" tab its own JAR library which contains for example a "com.custom.DITAExtensionsBundle" which extends our "ro.sync.ecss.extensions.dita.DITAExtensionsBundle" and overrides its "getClipboardFragmentProcessor()" so that you can gain control over the default clipboard fragment processor.

Once you have your own extension of the DITA framework you can distribute it as an extension point in the plugin:
https://www.oxygenxml.com/doc/ug-editor ... nsion.html

In general people should implement plugins if they want to add custom side views or buttons which interact with XML documents no matter to what vocabulary they belong.
And they would implement a DITA framework extension if they want to limit their editing customization to a certain vocabulary:
https://www.oxygenxml.com/doc/ug-editor ... guide.html

I do not know what else your plugin does besides adding the clipboard fragment processor, but maybe instead of choosing to implement a plugin you could have implemented a DITA framework extension configuration instead.

Regards,
Radu

[ralfpeterkorte]

Hi Radu,

thank you for your detailed explanation and all the hints.

I realized that the default implementation is called before my own ClipboardFragmentProcessor implementation.
That was the reason I asked how to disable it ( from a plugins view ).
I tried to use the removeClipboardFragmentProcessor( DITAUniqueAttributesRecognizer) while including dita.jar as system
dependency for testing purpose - couldn't find a maven artifact for dita.jar. Unfortunately removing didn't really work. I didn't pursue this any further because of the "hard" dependency to dita.jar. Or is there a maven artifact I've overseen?

Indeed we already do a lot of other functionality in our plugin, therefore I did not want to open another construction site by adding a framework extension. In the meantime I came along with a solution that reads the ids from the copy selection and remembers them for later use in my ClipboardFragmentProcessor. This should only be a fallback in case it is not possible to disable the default implementation of ClipboardFragmentProcessor from the plugin. It looks like it is now the final solution.

best regards,
Ralf Peter

[Radu]

Hi Ralf,

I tried to use the removeClipboardFragmentProcessor( DITAUniqueAttributesRecognizer) while including dita.jar as system
dependency for testing purpose - couldn't find a maven artifact for dita.jar. Unfortunately removing didn't really work. I didn't pursue this any further because of the "hard" dependency to dita.jar. Or is there a maven artifact I've overseen?

The "removeClipboardFragmentProcessor" method needs to receive an actual object of a certain class (and not the class itself) and you cannot access the actual object which is an instance of DITAUniqueAttributesRecognizer and was added.

Indeed we already do a lot of other functionality in our plugin, therefore I did not want to open another construction site by adding a framework extension. In the meantime I came along with a solution that reads the ids from the copy selection and remembers them for later use in my ClipboardFragmentProcessor. This should only be a fallback in case it is not possible to disable the default implementation of ClipboardFragmentProcessor from the plugin. It looks like it is now the final solution.

I see no other way to completely disable the base ClipboardFragmentProcessor just from the plugin side other than the idea of using a DITA framework customization.

Regards,
Radu