Community
Participate
Working Groups
Need to have a general XPath content assistance extension point, that reads in an XML File that contains information about the XPath's that a particular plugin may provide.
We probably need to create a generic interface for this. The idea being, by implementing an extension point, a particular XPath interpretor could provide through an interface, the functions that it understands. This would allow for the ability of user defined or extension functions to be defined in a generic way. Currently, Xalan in the org.apache.xpath.compiler.FunctionTable class, it has the ability to retrieve a list of all the built in xpath functions. The first item will probably be to get the Xalan support and code suggestions working for XPath completion, and then factoring it out to a more generic framework.
I'm not sure you are aware of this, but the BPEL editor in the Eclipse technology project contains a full XPath validation and assistance component. Check out the plugins in :pserver:anonymous@dev.eclipse.org:/cvsroot/technology. Key issues: * The BPEL editor uses the properties view to show the XPath expression (since it primarily uses a graphical editor). I'm not sure how that would work in the XML editor. * I'm not sure if the XPath editor itself can easily be extracted for use in WST sourceediting, and thus XSL. The BPEL product is pretty big and relatively stable, with some development going on at the moment (another committer added in February). Current HEAD has minor compile errors (reliance on internal 3.3 classes), but there could be a branch for 3.4 that I wasn't aware of. Does this sound like an idea? I can take a closer look.
Thanks for the note on this....I may take a look at what it has for XPath content assist and see if we can use it for the XML Editor itself as well. This would go partially with the support I've added in bug 213849, but I'm always willing to learn to see how somebody else has done it. The code I have so far for bug 213849 is checked into head. If we do it right, we can leverage the same same content assist api between the XPath Views and the XML Editor.
re-assigning to jesper.
Jesper...I took a look at the bpel code, and it doesn't look like it would be too difficult to modify it to work within our framework. I'll look at seeing if I can combine what they have (with appropriate credits), into our project. It'll be similar to what JSDT did with some of the JDT code to modify it for java script specifics. Give me a day or two and I'll pst an update on bug 213849.
Jesper, I've checked in some code that you might be able to leverage with the XPath Navigator and the new XPath Views for helping with the Content Assistance for XPath. Everything is checked in. I didn't end up using the BPEL items, as it was going to be a lot of work, and inclusion of extra models. I did borrow the idea though for adding them as Templates, which works out well, as it allows users to add their own templates to be used during the content assist. Anyways take a look at the XSLContentAssistProcessor, to see how I'm doing it for the XML Editor.
Jesper, do you think it would be beneficial for us to refactor the XPath content assistance support into a separate plugin that can then be used amongst the various views. Right now I have this solely in the xsl.ui plugin, but it might be more useful pulled out into it's own xpath.ui plugin to be reused amongst the various views and packages.
Mass Migration to wtp.inc.xsl
XPath Content assistance is treated as Templates. An adopter can use the templates mechanism to contribute specific additional help. Resolving this as fixed for now.
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
