How to store and access state variables?

[Krille]

Hi,

I'd like provide access to some strings, that are generated by an AuthorOperation through editor variables. Just like ${answer(@id)} provides access to the result of ${ask(..., @id)}.

My SurroundWithAnchorsOperation operation has the instance variables (or getters) startId, endId and containerXPath. And I'd like to provide access to information about the last inserted pair of anchors via ${startAnchorId}, ${endAnchorId} and ${anchorContainerXPath}. The reason: I'd like to use them in the next author action in a chain of actions. (I know how to concatenate operations in Java, but I'd like to do it in author action definitions using XML.)

I do know how to write an EditorVariablesResolver and how to activate it with AuthorExtensionStateListener. I've done that for custom editor variables. But I've not done it for a variable that provides access to an author action's state.

How can I do that?

I've read in the API docs and tried to find an instance object, to which there is access from the author action for storing the state and to which there is access from the editor variables resolver for reading it. A candidate could be the WSOptionsStorage instance which can be accessed via PluginWorkspaceProvider.getPluginWorkspace().getOptionsStorage() and then use setOption() to store the strings in the author action and getOption() to get the strings in the editor variables resolver.

But the OptionsStorage seems to be dedicated to configuration options, isn't it? So it feels a bit like misuse.

Is this a suitable approach?

Kind regards
Christian

[Krille]

I also would like to know, how to register an EditorVariablesResolver for text mode.
The way, that I described, registers it only for author mode.

[Radu]

Hi,
Sorry for the delay, we are experiencing some internal forum notification related problems.
Please see some remarks below:

I do know how to write an EditorVariablesResolver and how to activate it with AuthorExtensionStateListener. I've done that for custom editor variables. But I've not done it for a variable that provides access to an author action's state.

Did you implement a plugin for Oxygen XML Editor or do you have a custom framework configuration with certain Java extensions?

But the OptionsStorage seems to be dedicated to configuration options, isn't it? So it feels a bit like misuse.

Indeed any key, value pair you set there gets also saved also in the Oxygen global settings so it probably works but as you say it's a bit like misuse.
You could probably also create your own static class with static fields in which to set values on one side and obtain them on the other.
Or pass them as system properties using "java.lang.System.setProperty(key, value)" on one side and then reading the property on the other.

I also would like to know, how to register an EditorVariablesResolver for text mode.
The way, that I described, registers it only for author mode.

From what part of your code are you calling the "ro.sync.exml.workspace.api.util.UtilAccess.addCustomEditorVariablesResolver(EditorVariablesResolver)" method more exactly?
An Oxygen plugin could call the API when Oxygen is first started and the resolver will be called in all cases when Oxygen expands editor variables, no matter if working in the Text or Author modes. But I do not yet understand if you only have a framework Java customization or also an Oxygen Workspace Access plugin.
https://www.oxygenxml.com/doc/versions/ ... lugin.html
For the Text editing mode we do not have support in a framework configuration for adding toolbar actions.
A workspace access plugin could add toolbar and menu actions directly from the Java code which could work with the content in the Text editing mode but the API of the Text page is more limited and primitive.
https://www.oxygenxml.com/InstData/Edit ... rPage.html

Regards,
Radu

[Krille]

Hi Radu,

it's a custom framework, not a plugin. It's online:
https://github.com/SCDH/oxbytei

Thank you for the hints regarding the storing of state! I'll have some experiments with either approach and let you know, which one works fine.

The editor variables resolver is also part of the custom framework. In the exf-File, I use

Code: Select all

  <extensionPoints>
      <extension name="authorExtensionStateListener" value="de.wwu.scdh.oxbytei.OxbyteiStateListener"/>
  </extensionPoints>

to register the state listener, and then in the state listener, I use

Code: Select all

    @Override
    public void activated(AuthorAccess authorAccess) {
	authorAccess.getUtilAccess().addCustomEditorVariablesResolver(oxbyteiEditorVariables);
    }

where oxbyteiEditorVariables is an instance of my editor variables resolver implementation.

This way, the resolver is used for author mode, only. But not for text mode.

Regards
Chris

[Radu]

Hi Chris,

I understand, the authorExtensionStateListener API is Author page specific and it is not called when the document is opened in the Text editing mode.
Also the "activated" callback is called for each XML document which gets opened or switched to the Author visual editing mode, I hope that you remove your "oxbyteiEditorVariables" resolver on the "deactivated" callback otherwise you will keep adding it whenever a new XML document is opened in the Author mode.
As I previously said an Oxygen specific plugin could call the "authorAccess.getUtilAccess().addCustomEditorVariablesResolver" only once when Oxygen is opened.

Regards,
Radu

[Krille]

Hi Radu,
yes, the resolver is removed on deactivate() because I don't want to have several instances of the same resolver.

I guess, for a plugin it is rather

Code: Select all

PluginWorkspaceProvider.getPluginWorkspace().getUtilAccess().addCustomVariablesResolver(myResolver)

instead, isn't it?

I could put my variables resolver into a plugin. Then, I would like to share the class loader between my plugin and my framework, as described here:
https://www.oxygenxml.com/doc/versions/ ... lugin.html
How would you do that with a framework extension script?

Regards
Christian

[Radu]

Hi Christian,

You can find a sample workspace access plugin here:
https://github.com/oxygenxml/sample-plu ... ace-access

The plugin extension is called after the application is started and receives a reference to the "StandalonePluginWorkspace" field which allows it to add menu and toolbar entries or to add an editor variables resolver.

I'm afraid the framework extension script does not seem to have the ability to set a parent classloder plugin ID, I added an internal issue to look into adding this capability to the script in a future version.

A plugin's "plugin.xml" can refer to libraries using a certain local or global "scope":
https://www.oxygenxml.com/doc/versions/ ... _libraries

If the scope is global I think the framework's Java code should be able to access static fields from the plugin code.

Regards,
Radu

[alex_jitianu]

Hi Christian,
We've just released Oxygen version 24.1 and now it is possible to specify a plugin class loader in the framework script:

Code: Select all

<classpath parentClassLoaderID="com.oxygenxml.git"></classpath>

I hope it helps!
Alex