Community
Participate
Working Groups
I'm opening this bug as a spin-off from bug 89469 to contribute the XPath navigator view of the Orangevolt XSLT plugin. This enhancement will be contributed in the form of a patch against org.eclipse.wst.xml.ui, unless I head otherwise. Patch is (will be) modified relative to the Orangevolt original in these areas: + Separate XPath view from the main XSLT functionality as it has a broader application + Dependency on Xalan removed, instead uses javax.xml.xpath API from Xerces 2.8.0 from Orbit (already a dependency in WTP) - Collect XML namespace prefixes and feed these to XPath engine - New icons? Longer term: - Content assist for XPath would be sweet (will be put into separate issue when this one is closed) + means done - means pending Patch will be uploaded here as the issues above are resolved.
jesper, do we really need the xalan dependency ? java 5 already provides built in xpath support. in other word java 5 as a requirement frees the contribution from being dependent of xalan.
(In reply to comment #1) > jesper, > > do we really need the xalan dependency ? java 5 already provides built in xpath > support. in other word java 5 as a requirement frees the contribution from > being dependent of xalan. > No, exactly, we don't need it -- as I wrote, the Xalan dependency is removed (that required porting the Xalan-specific XPath API usage to the javax.xml.xpath API). That part's done already. One more thing I'd like input on: Support for XML namespaces is kindda tricky. I'm thinking about collecting the list of available namespaces from the XML instance itself, reusing namespace prefixes as we find them, and generating fresh namespace prefixes as required, and listing them on content assist in the XPath text widget. Does that sound right to you?
(In reply to comment #2) > One more thing I'd like input on: > > Support for XML namespaces is kindda tricky. I'm thinking about collecting the > list of available namespaces from the XML instance itself, reusing namespace > prefixes as we find them, and generating fresh namespace prefixes as required, > and listing them on content assist in the XPath text widget. > > Does that sound right to you? Is there a way to use the SSE model to retrieve the namespaces?
(In reply to comment #2) > (In reply to comment #1) > > jesper, > > > > do we really need the xalan dependency ? java 5 already provides built in xpath > > support. in other word java 5 as a requirement frees the contribution from > > being dependent of xalan. > > > > No, exactly, we don't need it -- as I wrote, the Xalan dependency is removed > (that required porting the Xalan-specific XPath API usage to the > javax.xml.xpath API). That part's done already. > > One more thing I'd like input on: > > Support for XML namespaces is kindda tricky. I'm thinking about collecting the > list of available namespaces from the XML instance itself, reusing namespace > prefixes as we find them, and generating fresh namespace prefixes as required, > and listing them on content assist in the XPath text widget. > > Does that sound right to you? > sounds very nice jesper !
(In reply to comment #3) > (In reply to comment #2) > > One more thing I'd like input on: > > > > Support for XML namespaces is kindda tricky. I'm thinking about collecting the > > list of available namespaces from the XML instance itself, reusing namespace > > prefixes as we find them, and generating fresh namespace prefixes as required, > > and listing them on content assist in the XPath text widget. > > > > Does that sound right to you? > > > Is there a way to use the SSE model to retrieve the namespaces? > > > if there is a way to reuse the SSE model's namespace capabilites we should use it - definitely. it may be worth to take of look into the autocompletion processor of the xml editor (i.e. which already provides this feature).
Created attachment 77879 [details] Initial drop of the XPath navigator Ok, here is an attemt to fix most of the issues with the XPath Navigator originally from the Orangevolt XSLT plugin: + Fixed copyright messages + Ported to JAXP 1.3 XPath API (thus requiring Java 1.5) + Localized all strings + Added namespace prefix capability. + Split off as separate plugin (org.eclipse.wst.xml.xpath.ui), for easy testing. It should be easy enough to reconcile it back into xml.ui. Outstanding issues: - "Show in Source" doesn't work (since we clone DOM elements in result) - I'm not comfortable with the namespace dialog (the one in xml.ui) * more info than we need * tricky to edit (should have cell editors, will submit separate bug) - We don't harvest all prefixes (yet) - No content assist (yet?) - Could have more "smooth" integration with editor list. - Many discouraged access into xml.core and xml.ui Points of interest: - BPEL editor (in technology project) includes an XPath editor. Much cool, but much meshed in with the BPEL plugins. Enjoy, please comment on anything (code style). I know there could be many iterations here, but this is just as much an attempt to get the IP ball rolling as anything.
(In reply to comment #6) > Created an attachment (id=77879) [details] > Initial drop of the XPath navigator > Thanks Jesper. I think this looks pretty good from a code-contribution point of view ... I'll comment in next comment ... but not sure about "substance", only because I'm not that familar with xpath, or what tasks people might want accomplish with it. But, do have a few questions there too. I did some simple test with the CommandSheet.xml file from the XMLExamples project (which can be created with WTP). I found a query such as //point worked as I expected. I found a query such as //point[@x="128.0"] worked as I expected (at first I thought not, but then noticed I was using "128" instead of "128.0"). Very cool. But, some simple naive-user question ... this seems oriented to work on single files, from this special view? Wouldn't this functionality be useful in the "normal" search dialog? And put results in normal search results view? And capable searching through multiple files? Or, ... am I simple missing the type of tasks this is to be used for?
(In reply to comment #6) > Created an attachment (id=77879) [details] > Initial drop of the XPath navigator > Heres' some comments on content, simply as code contribution. I found there were some @Override annotations in XPathNavigator (first around line 145) that was giving a compile error, I guess since NamespaceContext is an Interface, not a class? I found the packages were not exported in the manifest.mf file, so I could not open the view, getting "class not found" errors. Both of those are pretty easy to fix, once I tracked it down, but .... you know, took slow me an extra 30-45 minutes to figure out what was going on, you know, was it "just me", or my environment, or the code, etc. So ... assuming it wasnt' just me (as maybe it still was, somehow?) it really saves time (and builds up your rep) to contribute things "ready to go" [and, don't get me wrong ... I'm only saying this as constructive advise ... I think you getting started and making this effort is GREAT, and just hoping to help it continue!]). Also, I noticed many "unused imports" and similar things that we'd prefer to have clean. One thing you might do, is "copy" the project settings from one of the other XML projects (e.g. xml.core) so the same warnings and some style things are consistent with the xml component ... that help you fix up and at least match the same level of sloppyness as the rest of our code ... I just say that admitting we're not all that great ... again, just giving you the most advice I can.
(In reply to comment #6) > Created an attachment (id=77879) [details] > Initial drop of the XPath navigator > Here's some comments and questions on logistics of how to handle this. First, If I understand it right, Jesper you took this code from Lars code and worked it into a contribution to make here, right? Hence, a "joint effort"? Hence, we'll need Lars to document here that this contribution is ok with him. You have, I think correctly documented this chain in the copyright statements, but normally, documented or not, it'd be pretty sticky for someone to take someone else's code and contribute it here :) Let me know if I've missed something. Second, I think rather than start the IP process with this code, we'd probably be just as well off to wait until we start an Incubation Project in WTP. I think either would take 2 to 4 weeks to get going, and I have a feeling, this isn't a "one shot" contribution, but will take some iteration and review from others before we decide for sure if it's going into the main stream (as far as I know, it will, but ... I'm just saying I'd need the experts like Craig to review, not to mention the community). I have started that Incubation process, so unless it's derailed for some odd reason, I think that'll be easier over all ... and if it does get derailed, we'll go back to Plan A. Again ... much thanks Jesper (and Lars? :) for getting this going.
(In reply to comment #7) > I did some simple test with the CommandSheet.xml file from the XMLExamples > project (which can be created with WTP). > > I found a query such as //point worked as I expected. > I found a query such as //point[@x="128.0"] worked as I expected (at first I > thought not, but then noticed I was using "128" instead of "128.0"). > > Very cool. But, some simple naive-user question ... this seems oriented to work > on single files, from this special view? Wouldn't this functionality be useful > in the "normal" search dialog? And put results in normal search results view? > And capable searching through multiple files? Or, ... am I simple missing the > type of tasks this is to be used for? My experience with a couple of similar views, are this. While it may seem like a good idea to put the Xpath in the search dialog, I tend to find from a users point of view, I rarely use the search dialog, other than to find a particular pattern in multiple files. The Xpath navigator from my point of view is more useful as a standalone view, that can be used during the development and potentially the debugging of XSLT and XQuery statements (especially if XPATH 2.0 is supported). When working with XSLT and XQuery, you typically have to create many Xpaths to extract the information that you want. In order to do this, you may just need to quickly verify that the Xpath statement you have created works against the xml instance you are using to test the XSLT/XQuery. It is much more user friendly to have a view open where the command is entered and the results shown, instead of having to go through a menu system with multiple tabs to enter the command and then pop up a seperate view to see the results. For running an XPath across multiple files, and showing the results, it might make sense to have that functionality in the Search dialog, but I would still keep the current view as proposed.
Hi guys. I have created an XPath view built on top of the SSE code for x-assist as you already suggested. I can attach the source here if you want, otherwise you can get it from the http://sourceforge.net/projects/x-assist site. The xml.ui plugin also adds a XML perspective (which includes the xpath view), and some other menu items I think.
(In reply to comment #10) > (In reply to comment #7) > > My experience with a couple of similar views, are this. While it may seem like > a good idea to put the Xpath in the search dialog, I tend to find from a users > point of view, I rarely use the search dialog, other than to find a particular > pattern in multiple files. > > The Xpath navigator from my point of view is more useful as a standalone view, > that can be used during the development and potentially the debugging of XSLT > and XQuery statements (especially if XPATH 2.0 is supported). When working > with XSLT and XQuery, you typically have to create many Xpaths to extract the > information that you want. In order to do this, you may just need to quickly > verify that the Xpath statement you have created works against the xml instance > you are using to test the XSLT/XQuery. It is much more user friendly to have > a view open where the command is entered and the results shown, instead of > having to go through a menu system with multiple tabs to enter the command and > then pop up a seperate view to see the results. > > For running an XPath across multiple files, and showing the results, it might > make sense to have that functionality in the Search dialog, but I would still > keep the current view as proposed. > Thanks Dave, this makes perfect sense and does sound useful (from my limited XSL hacking) ... and this info sounds like the perfect start for some infopop help! :)
(In reply to comment #8) > (In reply to comment #6) > > Created an attachment (id=77879) [details] [details] > > Initial drop of the XPath navigator > > > > Heres' some comments on content, simply as code contribution. > > I found there were some @Override annotations in XPathNavigator (first around > line 145) that was giving a compile error, I guess since NamespaceContext is an > Interface, not a class? Odd, I didn't get any compilation errors on that one, but with the settings from xml.ui (but with 5.0 compliance), they were wrong. But yes, that's an error. > I found the packages were not exported in the manifest.mf file, so I could not > open the view, getting "class not found" errors. That must be related to compilation errors, since the plugin itself need not export the package of the view class' to function (OSGi magic in IConfigurationElement.createExecutableExtension). Honestly, I did test this (PDE export, run on plain Eclipse+WTP) before submitting :-) > Both of those are pretty easy to fix, once I tracked it down, but .... you > know, took slow me an extra 30-45 minutes to figure out what was going on, you > know, was it "just me", or my environment, or the code, etc. Sorry, I really did try to make it easily available, and I didn't have any red squigglies when I uploaded it. And I still don't when re-testing with a clean 3.3+WTP 2.0. (I guess your global prefs must be more restrictive than mine) > Also, I noticed many "unused imports" and similar things that we'd prefer to > have clean. One thing you might do, is "copy" the project settings from one of > the other XML projects (e.g. xml.core) so the same warnings and some style > things are consistent with the xml component ... that help you fix up and at > least match the same level of sloppyness as the rest of our code ... I just say > that admitting we're not all that great ... again, just giving you the most > advice I can. Thanks, will do. Uploading a new one where the only warnings are discouraged accesses (since I don't quite know what to do with them). Thanks for the good advice.
Created attachment 77955 [details] Updated patch
Comment on attachment 77955 [details] Updated patch Cleaned up according to David M. Williams' review
(In reply to comment #7) > Very cool. But, some simple naive-user question ... this seems oriented to work > on single files, from this special view? Wouldn't this functionality be useful > in the "normal" search dialog? And put results in normal search results view? > And capable searching through multiple files? Or, ... am I simple missing the > type of tasks this is to be used for? originally i created the xpath navigator with the following idea in mind: you write an xslt stylesheet and have to edit an xpath expression (which is natural when doing xslt development) and now you want test the expression against the xml document. so i decided to implement the xpath navigator based on the openend xml files. in other words it was a usability decision :-)
(In reply to comment #9) > (In reply to comment #6) > > Created an attachment (id=77879) [details] [details] > > Initial drop of the XPath navigator > > > > Here's some comments and questions on logistics of how to handle this. > > First, If I understand it right, Jesper you took this code from Lars code and > worked it into a contribution to make here, right? Hence, a "joint effort"? david, jesper helped me a lot one year ago while porting eclipsexslt to eclipse 3.1. > Hence, we'll need Lars to document here that this contribution is ok with him. in other words he has the same permisssions at the sourceforge project than me (i.e. same for the eclipsexslt code) > Let me know if I've missed something. does that answer your question ? > Again ... much thanks Jesper (and Lars? :) for getting this going. your welcome.
(In reply to comment #10) > The Xpath navigator from my point of view is more useful as a standalone view, > that can be used during the development and potentially the debugging of XSLT > and XQuery statements (especially if XPATH 2.0 is supported). When working > with XSLT and XQuery, you typically have to create many Xpaths to extract the > information that you want. In order to do this, you may just need to quickly > verify that the Xpath statement you have created works against the xml instance > you are using to test the XSLT/XQuery. It is much more user friendly to have > a view open where the command is entered and the results shown, instead of > having to go through a menu system with multiple tabs to enter the command and > then pop up a seperate view to see the results. > > For running an XPath across multiple files, and showing the results, it might > make sense to have that functionality in the Search dialog, but I would still > keep the current view as proposed. > 1+ 100% agreed. thats exactly what i had in mind while developing the xpath navigator.
just a remark for further improvements on the xpath navigator : a history of executed xpath expressions would be nice.
Do we want to move this one to the Incubator until it is ready to graduate? It would be helpful for the XSL Tooling project.
yes, incubator seems best.
> on single files, from this special view? Wouldn't this functionality be useful > in the "normal" search dialog? And put results in normal search results view? > And capable searching through multiple files? Or, ... am I simple missing the > type of tasks this is to be used for? That is what XQuery and XPath 2.0 provide with the collection() function. The ability to search across multiple instances and return a result node-set(). Unfortunately I think the jaxp.xml.xpath api is XPath 1.0 specific, but I could be wrong on this.
I'm resolving this as this contribution is already in the 0.5M4 and 0.5M5 incubator releases. Any bugs with this contribution should be opened as separate bug reports.
Mass Migration to wtp.inc.xsl
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
