Dnd of Tag Elements

[SSC]

Thank you for your reply.
This really helped a lot and we are almost happy with the oxygen solution for a XML editor.

There are currentlythree things left we would really appreciate in the next oxygen releases :

• 1. You should offer an API for the ro.sync.ecss.component.AuthorTransferredObject object which we can use. Yesterday I debuged through all those unobfuscated classes and unfortunately realized that all valuable information is private and that there is no interface/API for it.
  2. It would be nice, if you put those programmatically generated menu items and toolbar items in your plugin.xml with the org.eclipse.ui.menues extension. We do like to remove a couple of them, because most of our customers do not need those special toolbar and menu items.
  3. A possibility to color the tags in your Author View programmatically.(I know you already mentioned that the implemention of this feature is in progress)

Shall I also post those issues in the feature request forum or is it adequate to leave those issues here and you could pass those feature requests to your developers.
IMHO I think those features would be very useful and not that difficult to realize.
I hope you welcome this feedback.

[Radu]

Hi,

So:

1. You should offer an API for the ro.sync.ecss.component.AuthorTransferredObject object which we can use. Yesterday I debuged through all those unobfuscated classes and unfortunately realized that all valuable information is private and that there is no interface/API for it.

I added this as an improvement request. This is easy to do but even if it gets done, the nodes in the transferred object will no longer be connected in the XML document (but there is in the transferred object data about the ancestors of those elements), so you can also try my suggestion to use the API and look at the selected nodes in the Author page when the object is dropped in your custom view.

2. It would be nice, if you put those programmatically generated menu items and toolbar items in your plugin.xml with the org.eclipse.ui.menues extension. We do like to remove a couple of them, because most of our customers do not need those special toolbar and menu items.

Specifying toolbar extensions directly in the Java code gives us flexibility for handling different types of documents (XML, XSL, CSS, PHP, Javascript, etc). This means that when opening a "CSS" the toolbar has fewer buttons for example.
Specifying extensions in the "plugin.xml" means hardcoding specific actions to specific places.
Can you give us an example of what specific actions you would like to remove for the end users?

3. A possibility to color the tags in your Author View programmatically.(I know you already mentioned that the implemention of this feature is in progress)

For now this is scheduled for Oxygen 14 (for next year), but I cannot guarantee a certain release, I'll update this forum post when it gets done.

Regards,
Radu

[SSC]

Specifying toolbar extensions directly in the Java code gives us flexibility for handling different types of documents (XML, XSL, CSS, PHP, Javascript, etc). This means that when opening a "CSS" the toolbar has fewer buttons for example.
Specifying extensions in the "plugin.xml" means hardcoding specific actions to specific places.

I am sorry but in this case you are wrong and I have to disagree.
With the org.eclipse.ui.menus extension you can use the "visibleWhen" feature for every single menu or toolbar item.

Here is an example used within the default eclipse view template application:

Code: Select all

<extension

         point="org.eclipse.ui.menus">

      <menuContribution

            locationURI="menu:org.eclipse.ui.main.menu">

         <menu

               label="File">

            <command

                  commandId="org.eclipse.ui.file.exit"

                  label="Exit">

[color=#FF0040]               <visibleWhen

                     checkEnabled="false">

                  <with

                        variable="activePartId">

                     <equals

                           value="GUI_Test.view1">

                     </equals>

                  </with>

               </visibleWhen>[/color]

            </command>

         </menu>

      </menuContribution>

 </extension>

In this example the ID of the active part is compared with my view1 ID.
On the following wiki page you can find more expressions which can be used to support the "visibleWhen" feature in org.eclipse.ui.menus .

http://wiki.eclipse.org/Command_Core_Expressions

In the table below the "Variables and the Command Framework" heading is also an "activeEditorId" which you could use like I did with my test view1 and the "activePartId".

So you could use something similar like this :

Code: Select all

<extension

         point="org.eclipse.ui.menus">

      <menuContribution

            locationURI="menu:org.eclipse.ui.main.menu">

         <menu

               label="Dita">

            <command

                  commandId="oxygen.dita.command1"

                  label="Some Dita command">

[color=#FF0040]               <visibleWhen

                     checkEnabled="false">

                  <with

                        variable="activeEditorId">

                     <equals

                           value="your.certain.oxygen.editorID">

                     </equals>

                  </with>

               </visibleWhen>[/color]

            </command>

         </menu>

      </menuContribution>

 </extension>

Can you give us an example of what specific actions you would like to remove for the end users?

We would like to leave out nearly all of your additional toolbar items, because our end users mainly only edit the xml content and do not transform anything or work with the underlying schema.

[SSC]

Now I use this code while knowing that the unobfuscated classnames may change in future releases...

Code: Select all

Object data = event.data;

if (data instanceof StructuredSelection) {

   StructuredSelection selection = (StructuredSelection) data;

   Object firstElement = selection.getFirstElement();



   if (firstElement instanceof ro.sync.ecss.component.lb) {

      kb[] fragments = ((ro.sync.ecss.component.lb) firstElement).getFragments();

      for (kb kb : fragments){

           AuthorDocumentFragment b = kb.b();

	   List<AuthorNode> contentNodes = b.getContentNodes();

	   for (AuthorNode authorNode : contentNodes) {

		adjustDataToAuthornNode(authorNode);

	   }

       }

    }



  if (firstElement instanceof AuthorNode) {

    AuthorNode node = (AuthorNode)firstElement;			  adjustDataToAuthornNode(node);

   }

}

In the adjustDataToAuthornNode method I compare the passed authorNode with the

Code: Select all

editorPage.getFullySelectedNode();

to be sure that editorPage.getFullySelectedNode(); is the node which I actually dropped.
Then I add a processing instruction to that node :

Code: Select all

documentController.insertXMLFragment("<? Test PI ?>", fullySelectedNode,			AuthorConstants.POSITION_BEFORE);

This solution works quite well, but except of this cast because of the missing interfaces/API we talked about.

Code: Select all

   if (firstElement instanceof ro.sync.ecss.component.lb) {

      kb[] fragments = ((ro.sync.ecss.component.lb) firstElement).getFragments();

This is really worse, but at least it works

My actual question is how can I check if an PI is already existend for that AuthorNode?

When I searched the forum I found this code snipped :

Code: Select all

AuthorDocument ownerDocument = authorNode.getOwnerDocument();

      AuthorElement rootElement = ownerDocument.getRootElement();

      List<AuthorNode> allDocumentNodes = ownerDocument.getContentNodes();

      int rootIndex = allDocumentNodes.indexOf(rootElement);

      if(rootIndex > 0) {

        AuthorNode nodeBeforeRoot = allDocumentNodes.get(rootIndex - 1);

        if(nodeBeforeRoot.getType() == AuthorNode.NODE_TYPE_PI) {

          try {

            String piContent = nodeBeforeRoot.getTextContent();

          } catch (BadLocationException e) {

            e.printStackTrace();

          }

        }

      }

I changed it so that I am asking for the index of the passed authorNode.

Code: Select all

allDocumentNodes.indexOf(authorNode);

But this only returns -1 which means it does not find the node and so I am not able to check if a PI is already existend or not.
Is there maybe another way to get a previous sibling of an authorNode? Although I am not really sure if a PI can be a real sibling of a XML tag.

Or is it possible to define in the schema that only one PI is allowed and insert this PI schema aware?

[Radu]

Hi,

In Oxygen 13.2 (probably in January next year) you will have these objects not obfuscated (which will break your existing code )

In my opinion, you should only look in the "selection.getFirstElement()" to see if it is an object coming from an Oxygen Author page (you can check on the object by reflection to see if it has a "getFragments()" method for example) and then look directly at the selection in the "editorPage.getFullySelectedNode()". I think that it's close to impossible that that selected node was not the one which was dropped in your custom view.

You added the custom PI using correct API.

Now for the question:

My actual question is how can I check if an PI is already existend for that AuthorNode?

So the Author page is a tree of AuthorNodes (similar to DOM nodes) which point in a single content string which contains all text nodes, an image for this can be found here:

http://www.oxygenxml.com/InstData/Edito ... gment.html

The code which you found iterates only in the children of the document (the comments, processing instructions + root element which are on the top level in the XML file).

I think your code should look more like this:

Code: Select all

    AuthorNode fullySelectedNode = edPage.getFullySelectedNode();

    if(fullySelectedNode != null) {

      //Maybe we have a processing instruction before it

      AuthorParentNode parent = (AuthorParentNode) fullySelectedNode.getParent();

      int indexOfFullySelectedNode = parent.getContentNodes().indexOf(fullySelectedNode);

      if(indexOfFullySelectedNode > 0) {

        AuthorNode previousNode = parent.getContentNodes().get(indexOfFullySelectedNode - 1);

        if(previousNode.getType() == AuthorNode.NODE_TYPE_PI) {

          //This should have both target and data

          String textContent = previousNode.getTextContent();

        }

      }

    }

About this question:

Or is it possible to define in the schema that only one PI is allowed and insert this PI schema aware?

Schema aware insertion is only concerned with inserting XML elements which adhere to the schema used to edit the XML file.
So you will have to make sure that your custom PI is not repeated.

Regards,
Radu

[SSC]

Thanks for your reply.

If in Version 13.2 those classes are not obfuscated any more or you offer an interface for those classes I would resign to use the solution with reflection and just wait until January. Using reflection and check whether it contains a certain method is IMHO not satisfactory, I then prefer to wait.

Your Code with the AuthorParentNode works really well.

Have you also seen my previous post about the org.eclipse.ui.menus extension?
http://www.oxygenxml.com/forum/topic6502-15.html#p20146

If you have futher questions about this extension I would offer my help for you. I think to choose the build in extensions of the powerful eclipse framework is better then using an own solution, which is not customizable for your customers (and after I finished evaluating your XML Editor we may also become your customer ).

[Radu]

Hi,

Have you also seen my previous post about the org.eclipse.ui.menus extension?

Sorry for the delay, we had a longer talk internally about this.
This approach seems possible so I added an improvement request to try and move the creation of most of our toolbars/menus to the plugin.xml.
This will not include the internal Author toolbar and menu which are contributed by the document type associated with the XML document.

Regards,
Radu

[SSC]

Sorry for the delay, we had a longer talk internally about this.

We also just had an internal meeting about the Oxygen XML Editor and I was nearly able to persuade the management to choose Oxygen as a solution. My job is now to do some final tests concering the integration of Oxygen into our eclipse CMS client.
To come back to the "delay" you mentioned... One of the most important argument for using oxygen is the great support and fast response time by you in this forum. I am really impressed by that. Keep at it

This will not include the internal Author toolbar and menu which are contributed by the document type associated with the XML document.

I expected that beforehand and this leads directly to one of the questions of our management: "Is it possible to extend or modify the internal Author toolbar?"

At least the management will be happy, if you realize my recommendation with the menu items and the even more important fact that you and your company are responsive to wishes of the customers.

I wish you a nice weekend then.
See you on monday

[Radu]

Hi Simon,

About this question:

Is it possible to extend or modify the internal Author toolbar?

Yes and no. The Author internal toolbar has two lines. The first line (Refresh buttons, change tracking actions, etc) is fixed and cannot be configured.
From what I remember we've had a previous user who actually dynamically navigated our MultiPageEditorPart hierarchy, found the coolbar and disposed a couple of toolbars from it.

The second line is dynamically contributed by the Document Type which corresponds to the edited XML file, document type which has been defined in the Document Type Association Oxygen preferences page:

http://www.oxygenxml.com/doc/ug-editorE ... orial.html

Regards,
Radu

[Radu]

Hi,

Oxygen 13.2 was just released, so the clipboard and drag and drop objects should now be exposed in the Java classes.

Regards,
Radu

[SSC]

Thanks for your hint

It´s really great to see how fast you have realized the requests of your customers. Thumbs up for that.

[SSC]

Hello Radu,

Some time ago we talked about the org.eclipse.ui.menus extension:

Have you also seen my previous post about the org.eclipse.ui.menus extension?

[...]
This approach seems possible so I added an improvement request to try and move the creation of most of our toolbars/menus to the plugin.xml.
[...]

The first thing I searched for, after downloading Oxygen version 14, was the org.eclipse.ui.menus extension in your com.oxygenxml.author plugin.xml file, but I was not able to find any org.eclipse.ui.menus extension.

Is it maybe possible for uns, as customers, to see the state of certain improvement requests, like the one concerning the org.eclipse.ui.menus extension improvement?

Best regards,

Simon

[Radu]

Hi Simon,

This was not implemented in 14.0. I cannot tell you a precise timeline for this because it implies a lot of modifications and architecture changes on our side.

Is it maybe possible for us, as customers, to see the state of certain improvement requests, like the one concerning the org.eclipse.ui.menus extension improvement?

No, sorry, our issues list is internal.

Regards,
Radu