custom authorOperation without changing the document

[Patrik]

Hi,

since I have quite a lot references that are resolved at runtime by a ReferenceResolver (e.g. by performaing an xslt transformation) I implemented a feature to expand/collapse a single or all content references in a document to improve the performance. This is invoked by AuthorOperations added with oxy_button through the css (oxy|reference:before).

Now when performing such an operation the actual content is not touched - only the way it is displayed. However, the document is still being marked as changed. Is there any way to mark the operation as "not changing the document"?

Thanks and regards,

Patrik

[alex_jitianu]

Hi Patrik,

There is an API that can be used to change the modified marker on an editor: WSEditorBase.setModified(boolean). In the AuthorOperation implementation you could do something like this:

Code: Select all

public void doOperation(AuthorAccess authorAccess, ArgumentsMap args)

  throws AuthorOperationException {

  boolean oldValue = authorAccess.getEditorAccess().isModified();

  try {

    ......code....

  } finally {

    if (!oldValue) {

      // If the document was not modified at the begining, mark it back as un-modified.

      authorAccess.getEditorAccess().setModified(false);

    }

  }

The only drawback is that even though the editor will not be marked as modified, the user will still be able to UNDO the effect of the operation.

Best regards,
Alex

[Patrik]

Hi Alex,

thanks for the tip. This works fine and we can live with the drawback.

Now another question in this context:
We have two css styles. "edit" to display additional buttons and text helping the author and "output" being as close to the final output as possible. Now in "output" I'd like to have the references always being displayed as expanded. To implement this, I'd need to have a listener for changing the selected css and the name or url of the current css. I could not find somethign like this in the api - does it exist?

Thanks and regards,

Patrik

[alex_jitianu]

Hi Patrik,

Unfortunately there isn't a built-in support for getting this kind of notifications. I can think of two possible workarounds though:

1. You could have one big CSS and use custom CSS pseudo-classes to differentiate between the "edit" and "output" states. To switch between the two states you must create author actions that use a custom operation like the built-in one:TogglePseudoClassOperation. The reason you need a custom operation is because after you set the pseudo-class you must probably call the AuthorDocumentController.refreshNodeReferences(AuthorNode). In your reference resolver you can check check if a pseudo class is set on the element: AuthorElementBaseInterface.hasPseudoClass() and decide what to do.

2. from an Workspace Access plugin you can add a ToolbarComponentsCustomizer. This special toolbar is populated each time the selected editor changes (with values for that editor) so you'll have to do something like this:

Code: Select all

final ToolbarInfo[] cssAlternatives = new ToolbarInfo[1]; 



pluginWorkspaceAccess.addEditorChangeListener(new WSEditorChangeListener() {

  ActionListener l = null;

  {

      l = new ActionListener() {

      @Override

      public void actionPerformed(ActionEvent e) {

        System.out.println("!!! " + e.getSource());

      }

    };

  }

  public void editorSelected(URL editorLocation) {

    install();

  }



  private void install() {

    ToolbarInfo toolbarInfo = cssAlternatives[0];

    if (toolbarInfo.getComponents().length > 0) {

      JComponent jPanel = toolbarInfo.getComponents()[0];

      if (jPanel.getComponentCount() > 0) {

        JMenu toolbarMenu = (JMenu) jPanel.getComponent(0);

        System.out.println("Toolbat name " + toolbarInfo.getTitle());

        int menuComponentCount = toolbarMenu.getMenuComponentCount();

        for (int i = 0; i < menuComponentCount; i++) {

          final JMenuItem item = (JMenuItem) toolbarMenu.getMenuComponent(i);

          item.removeActionListener(l);

          item.addActionListener(l);

        }

      }

    }

  }

}, PluginWorkspace.MAIN_EDITING_AREA);



pluginWorkspaceAccess.addToolbarComponentsCustomizer(new ToolbarComponentsCustomizer() {

  /**

   * @see ro.sync.exml.workspace.api.standalone.ToolbarComponentsCustomizer#customizeToolbar(ro.sync.exml.workspace.api.standalone.ToolbarInfo)

   */

  @Override

  public void customizeToolbar(ToolbarInfo toolbarInfo) {

    if ("Author CSS Alternatives".equals(toolbarInfo.getTitle())) {

      cssAlternatives[0] = toolbarInfo;

    }

  }

});

If you need any more details about any of the workarounds please let me know. I hope I haven't overlooked something potentially important...

Best regards,
Alex