Community
Participate
Working Groups
The current implementation only honors the usage of IDs to decide where to contribute which makes it hard to make contributions to products you don't control your own. We should provide the possibility to use XPaths to contribute in a more generic fashion. Current: ---------8<--------- <fragments xsi:type="fragment:StringModelFragment" featurename="handlers" parentElementId="app.simpleide"> <!-- --> </fragments> ---------8<--------- Future: ---------8<--------- <fragments xsi:type="fragment:StringModelFragment" featurename="handlers" parentElementPath="/MApplication"> <!-- --> </fragments> ---------8<--------- To implement XPath we can simply use org.apache.commons.jxpath from orbit. The other possibility is to use OCL but I'd favorise XPath.
Created attachment 178681 [details] EMF/XPath implementation Project with an EMF-XPath implementation
Created attachment 178682 [details] implementation
Ed, is EMF itself interested in the EMF/XPath implementation (see the zip) I've developed here because I need to file a CQ to reuse JXPath from Orbit. When it is getting which component would it get part of?
Created attachment 178683 [details] EMF/XPath implementation
Boris, I case EMF is not interested and I've simply copied code from JXPath's bean implementation do I also have to submit my EMF-XPath implementation to the IP-Team (I've kept the copyright apache headers because 90% code is equal to the original Bean implementation)?
I think I'll go on with doing this in e4 for now so I'll file a CQ to reuse JXPath
Created attachment 178691 [details] sources i sent to IP team for review (without tests)
I'm not sure about the bundle name. I've for now used: org.eclipse.e4.emf.xpath but I'm open for other suggestions (e.g. org.eclipse.e4.core.emf.xpath)
The CQs are: * CQ 4460 to reuse JXPath 1.3 * CQ 4461 for the code contribution which has ~90% copied code from JXPath
Tom, is there a reason you can't use the XPath implementation that comes with the Java class libraries (javax.xml.xpath)?
Please note that JXPath is used to write our own XPath-Interpreter which works on EObject-Graphs
http://commons.apache.org/jxpath/ to see what JXPath is for.
I see, thanks. I didn't dig into your code, and thought you just wanted to use jxpath as a simple xpath processor.
It sounds cool and useful. I'll not have time to look closely until late in the week. I thought I remembered JET2 having something like this...
It does look cool. I'd want to make it a separate feature from the rest of the core runtime, but it would definitely be a useful addition to the core.
(In reply to comment #15) > It does look cool. I'd want to make it a separate feature from the rest of the > core runtime, but it would definitely be a useful addition to the core. That's perfectly ok with me and because I'm already a EMF committer it shouldn't be a problem. Does anyone here know if we can move the CQs i filed to another project CQ 4460 has already been approved and CQ 4461 is under review.
Sounds good to me...I can see how this might solve a number of issues when contributing to 'non-child' containers such as the Trim and DWs... Are there particular things we should be looking at to support this correctly? Reserving schema names...
No need for this perserved namespaces, ... - the XPath is applied to the In-Memory-Object-Graph (it simply calls the reflective eGet()-API and use eClass-informations) you only use the well known XPath syntax
The IP-Team approved the code and I've been allowed to check in in accordance with Parallel IP. I've for now checked in the EMF-XPath implementation into the e4-repository before I submit the patch to use this new code in e4. I think we should add this code to the build. Paul anything you need for me to help you get this into the e4-build?
we yesterday discussed the problem that we'd like to contribute one fragment to multiple elements. Something like this: --------8<-------- <fragments xsi:type="fragment:StringModelFragment" featurename="children" parentElementPath="/children/mainMenu/children[0]"> <handledmenuitem xmi:id='1234-1234-1234' label='Close'> <bla xmi:id='1234-1234-1234' /> </handledmenuitem> <handledmenuitem xmi:id='5678-5678-5678' label='Close All' /> </fragments> --------8<-------- Now suppose we have an Application.xmi with 2 windows: --------8<-------- <application> <children label="Window 1"> <mainMenu> <children label='File' xmi:id="1111-1111-1111"> </children> </mainMenu> </children> <children label="Window 2"> <mainMenu> <children label='File' xmi:id="2222-2222-2222"> </children> </mainMenu> </children> <application> --------8<-------- if we now contribute one of our snippets multiple times we have to ensure that the resulting xmi:id-s are: * unique * stable (the same of every startup) As it is today we simply copy the xmi:id when creating the model which would create an illegal model like this: --------8<-------- <application> <children label="Window 1"> <mainMenu> <children label='File' xmi:id="1111-1111-1111"> <handledmenuitem xmi:id='1234-1234-1234' label='Close'> <bla xmi:id='1234-1234-1234' /> </handledmenuitem> <handledmenuitem xmi:id='5678-5678-5678' label='Close All' /> </children> </mainMenu> </children> <children label="Window 2"> <mainMenu> <children label='File' xmi:id="2222-2222-2222"> <handledmenuitem xmi:id='1234-1234-1234' label='Close'> <bla xmi:id='1234-1234-1234' /> </handledmenuitem> <handledmenuitem xmi:id='5678-5678-5678' label='Close All' /> </children> </mainMenu> </children> <application> --------8<-------- So I think the only solution for this multi-fragment contribution is that we are building up the ID from the parent and contributed element (please note that this is also includes any sub-item in this contributed element). --------8<-------- <application> <children label="Window 1"> <mainMenu> <children label='File' xmi:id="1111-1111-1111"> <handledmenuitem xmi:id='1111-1111-1111_1234-1234-1234' label='Close'> <bla xmi:id='1111-1111-1111_1234-1234-1234' /> </handledmenuitem> <handledmenuitem xmi:id='1111-1111-1111_5678-5678-5678' label='Close All' /> </children> </mainMenu> </children> <children label="Window 2"> <mainMenu> <children label='File' xmi:id="2222-2222-2222"> <handledmenuitem xmi:id='2222-2222-2222_1234-1234-1234' label='Close'> <bla xmi:id='2222-2222-2222_1234-1234-1234' /> </handledmenuitem> <handledmenuitem xmi:id='2222-2222-2222_5678-5678-5678' label='Close All' /> </children> </mainMenu> </children> <application> --------8<-------- I think this is the only solution to our problem, or does someone else have another idea?
Ok we just discussed a bit on IRC. Let me first of all explain the how the current id based fragment system works: The only implementation we currently provide to contribute is "StringModelFragment" which has the following attributes: - featurename: the feature you want to contribute to "e.g. children" - parentElementId: the id of the parent element "e.g. app.window1" - positionInList: special syntax to contribute at a certain point in the list (only takes effect for multi valued features) * <empty>: append to the list * first = insert at the beginning of the list * index:$i = at the specified index in the list * after:$id = after the element with the specified elementId * before:$id = before the element with the specified elementId now let's think how an XPathModelFragment contribution could look like. I think all it needs is the attribute "xpath" and provide the following syntax: * ($action)?:$xpath $action: append, before, after Some examples might make this clear: Multivalued features: "append:/children/mainMenu/children[0]/children" appends the fragment to the children list "before:/children/mainMenu/children[0]/children[@elementId='blabla']" inserts before the element "after:/children/mainMenu/children[0]/children[@elementId='blabla']" inserts directly after the element Singlevalued features: "/children/mainMenu" set the contribution to the mainMenu-Feature
just one more note. I really like this approach but there's one thing I'm not sure what should happen when we are not finding: "before:/children/mainMenu/children[0]/children[@elementId='blabla']" is the the contribution then made on the children and simply appended? We could probably say that people can define n-xpaths and the first one which succeeds is the correct one :-)
With shifting stuff around, org.apache.commons.jxpath and org.eclipse.e4.emf.xpath are not in the org.eclipse.e4.rcp feature anymore in 4.2. They're not missed, as there are no compile problems. Is that a problem? Is it OK to look at this again in 4.3? PW
Tom, the org.eclipse.e4.emf.xpath bundle graduated into eclipse.platform.ui with other core parts of the Eclipse4 technologies. What do you think should be done to it if we want to move forward with this? Were there changes you discovered when doing XPath<->EMF that should be integrated into this bundle? http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.emf.xpath
The XPath syntax is available for a while now. *** This bug has been marked as a duplicate of bug 437958 ***
