Bugzilla – Full Text Bug Listing
| Summary: | [xslt][editor] XPath content assist does not complete | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Doug <doug.satchwell> |
| Component: | wst.xpath | Assignee: | David Carver <d_a_carver> |
| Status: | RESOLVED FIXED | QA Contact: | David Williams <david_williams> |
| Severity: | normal | ||
| Priority: | P3 | CC: | d_a_carver, Ed.Merks, jesper |
| Version: | unspecified | ||
| Target Milestone: | 3.1 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 217822 | ||
|
Description
Doug
Also, when I choose a completion and press enter, it should fill in the remainder of the word e.g. if I type 'tran' and select 'translate' the completion should add 'slate' to the end (at the moment it inserts 'translate' so that the word becomes 'trantranslate'). Targetting for M7...shouldn't be difficult as there is already some sample code out there for this particular functionality, just need to implement. Don't have time before 0.5M6, but will implement for 0.5M7. I have a partial fix for this, but only for variables at this time. Content completion needs to be revisted during m7 to address several issues related to this: 1. Content completion was orginally designed for an all or nothing completion. So the base completion proposal within attributes always expects to replace the entire string. To get around this some special classes were created to allow inserting of the text instead of complete replacement. However this leads to the current implementation and this particular bug. 2. I have managed to create the necessary code to complete the variables, however, it doesn't show any content assistance after this because it's using the input string as a filter on the proposal list. Some extensions and overrides of methods will be needed. A typical XPath expression or XSLT test expression can have the following separators: space[]*+-/::"'() If any of the above occur within the select when CTRL-SPACE is hit, then we should ignore the text that came before the last separator character and allow full content assistance. The other thing that should be done, is that the XPath functionality really should be modeled out to provide further help within the xpath functions themselves. To only provide hints for variables or functions that can be inserted at particular points. To do this may require some modeling of XPath functions. I believe the BPEL project has an EMF model for this very thing which we might be able to reuse. Copying Jesper on this as well for his thoughts. It would be good to have some way of checking XPaths - we could re-use it to help with bug 224938 (we could check the validity of an XPath regardless of whether extension functions are used), and also for the XPath view (we could offer code completions and check validtity). And come to think of it, bug 225418 too since we need to parse the Xpath in order to determine where to place the hyperlink. Doug, I'll work on this for M7 since I think XPath content assistance needs to be reworked and split into it's own plugin. Okay, I've done some tweaking for some rework of the Content assistance. Functionally, there will be no change at the moment from the users point of view. Internally, I've currently set all XML_TAG_ATTRIBUTE_VALUE regions, as as XSL_XPATH partions. Again, functionally there should be no difference.
The next step is to limit that partion only to areas that are within the XSLT namespace and only for the following attributes:
select, test, match. The other area to setup the partion is in any attribute that has { } in it.
These regions will then have their own values, and content assistance will be specific to the particular region. This may mean many smaller regions within the partions for XSL_XPATH, but it allows finer grain control and will work better with the existing Eclipse content assistance.
Created a Class for unit testing the Content Proposals. This will be used to help make sure that the various proposals are valid and what is expected. The 'tran' option will currently work, only if you are at the beginning of the selection statement. The expressions within the select, test, and { } need to be parsed, and indexed. Currently the completion code isn't really that testable, so I'll work on refactoring so that it is more testable for the various regions first.
Added a dependency on the apache commons jxpath bundle. This is currently needed as it provides a public interface into it's XPath Parser and Compilers so that a user can step through the tokens of an xpath statement. This is needed so that exact positioning within the xpath statement can be done for content assistance. It provides begging column and ending column numbers as well as some other useful information regarding the various tokens. Separately, an EMF model and code have been included to model out the various pieces of an XPath statement. A model is required to help provide some future functionality and to help provide information about what data values are allowed at specific function arguments. This will also help with identifying the cardinality of the arguments. This may lead to the removal of some of the XPath templates, but for now they will stay. Also during this change the experimental Xalan specific validator has been removed, as it was going to be too much work to make it useable at this time. Cool - I'll have to have a look at this EMF stuff because it might be possible to use it for the XSL model too. BTW - I think it might be an idea to split the Xpath stuff out into another plugin org.eclipse.wst.xml.xpath.core?? We already have a org.eclipse.wst.xml.xpath.ui plugin (currently just the Xpath views, but can contain other things like the templates)...it would seem to add some symmetry. (In reply to comment #12) > Cool - I'll have to have a look at this EMF stuff because it might be possible > to use it for the XSL model too. Funny, you should mention that. I already ran a proof of concept with Ed Merks, on taking the XSLT 1.0 XSD and generating an EMF model from it. We found one bug in EMF that has since been fixed, so you could get the model that way. The nice thing is if it is done right, you could get a nice complete model with all included and imported stylesheets, which would allow some very cool content assistance to take place. I'm CCing Ed on this as well. > > BTW - I think it might be an idea to split the Xpath stuff out into another > plugin org.eclipse.wst.xml.xpath.core?? We already have a > org.eclipse.wst.xml.xpath.ui plugin (currently just the Xpath views, but can > contain other things like the templates)...it would seem to add some symmetry. > Yeah, I was thinking that myself. I'll probably end up doing that later in the week. Adding Ed to this as I may have EMF questions that are better tracked here for prosperity. Created two new plugin, per Doug's suggestion: org.eclipse.wst.xml.xpath.core org.eclipse.wst.xml.xpath.core.tests These now are the home for the XPath specific functionality being developed for parsing and model generation. This can be the base for expanding later functionality for XPath 2.0 as well. These have not been added to the map file yet. Also, JXpath from Apache commons has be approved for our reuse from Orbit. CQ2285 is the appoval in ipzilla. Retargeting to 0.5M8 Refactored some of this code to help clean it up a bit and to simplify the implementation so far. The XPath specific template completion information has been moved to the org.eclipse.wst.xml.xpath.ui plugin to be consistent with where the other XPath completion information is stored. XSL specific functionality is still within the xsl.ui plugin where it should be. All unit tests are passing as before. Items still to do: 1. Implement XPath parsing in the XSL Content Assistance....this might get refactored into a more specific class later. 2. Implement position based insertion/completion based on the new calculated offset based on the parsed information of the xpath parser. The above two items should allow better content completion. There may need to be some additional tweaking to make sure that the whole Xpath doesn't get replaced. I have this successfully implementing the content completion. It correctly identifies the various XPath tokens, like parens, brackets, commas, and other items, and sets the starting replacement position after that token. It then calculates where the cursor actual is in the expresion, and will calculate the replacement length. Based on this information it will extract the match string, and filter the list of proposals. So as you type the list is filtered, and when your replace the text, it will correctly complete the text instead of inserting the whole proposal text plus what you had already typed. There are still a few more unit tests to run and create, but this is much better than before. Note this has currently been tested with single line xpaths, still need to do testing when the xpath breaks across multiple lines. This appears to be working for about 90% of the cases I've gone through. A few little oddities are still to be worked out and in certain cases the replacement offset is off by 1. These will be handled in 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. |