Bugzilla – Full Text Bug Listing
| Summary: | [xpath] Clean up XPath UI plugin | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Doug <doug.satchwell> |
| Component: | wst.xpath | Assignee: | David Carver <d_a_carver> |
| Status: | RESOLVED FIXED | QA Contact: | Doug <doug.satchwell> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | david_williams, d_a_carver |
| Version: | unspecified | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Doug
Also, the XPath view code should be in a package ui.internal.views, and the content and label providers should be deleted and replaced with the IAdapterFactory/IWorkbenchAdapter mechanism (same as for the XSL model). (In reply to comment #0) > The XSL UI plugin contains 2 source directories, which would be better as one. > Also, the plugin class should be in the internal package. And the XPath > Navigator view code is no longer used, so should be removed. > I think you mean xsl.core, and there is a reason for the two directories, as I would like to keep SSE specific code in a separate directory so that it is easier to find and maintain. If everything is kept under one source directory it can become more difficult to find what is related to specific sub-sections of the code. Also, JDT, Platform, and several other existing eclipse projects as well as WTP follow this method in several projects. (In reply to comment #1) > Also, the XPath view code should be in a package ui.internal.views, and the > content and label providers should be deleted and replaced with the > IAdapterFactory/IWorkbenchAdapter mechanism (same as for the XSL model). > Agree that the XPath view should be refactored and moved to an internal package. I'd like to discuss the reasoning of moving the SSE source into one source folder before we actually commit to do it. (In reply to comment #0) > Navigator view code is no longer used, so should be removed. Actually, I find the XPath Navigator useful at times....would it be a possiblity to add some of it's functionality where you can specify a document to be used without having to actually open one in the editor. There are times when it's nice to just specify a document to be used instead of actually opening, especially if the document is extremely large and you are testing out some xpath's you are developing to access information in the document. So before we get rid of it, I'd like to see some of that functionality added to the XPath View. I actually meant XPath UI, so don't worry its nothing to do with the sse code. The navigator is a little bit naughty in that quite a bit of the code lives in the plugin class, instead of the view where it belongs. We should at least move that if we are to keep the navigator. But I wonder if what we really need is a Search dialog that runs xpaths against a batch of files (without needing to open the files being searched)? This I think would be more in keeping with the way Eclipse works for other languages. Corrected the name (In reply to comment #4) > I actually meant XPath UI, so don't worry its nothing to do with the sse code. > But I wonder if what we really need is a Search dialog that runs xpaths against > a batch of files (without needing to open the files being searched)? This I > think would be more in keeping with the way Eclipse works for other languages. I think David Williams had mentioned something about this several months ago. Is the search going to be on a single file or multiple files? If multiple you are almost better implementing this functionality in the propose XQuery editor as you could run an XQuery to search across the eclipse projects and parse everything in a collection. If we are talking an individual file, then I like the view for testing purposes. The beauty of using a search dialog is that you can specify the range of files you want to run the search on. It can be the single file you currently have selected in the viewer, or a selection of files, or a project, or the entire workspace. It would be a good idea to combine both XPath and XQuery in a single search page so that you can use either for searching, so yes the XQuery proposal is a good place to put that. (In reply to comment #7) > The beauty of using a search dialog is that you can specify the range of files > you want to run the search on. It can be the single file you currently have > selected in the viewer, or a selection of files, or a project, or the entire > workspace. > > It would be a good idea to combine both XPath and XQuery in a single search > page so that you can use either for searching, so yes the XQuery proposal is a > good place to put that. > Yeah, this the type of functionality that XPath 2.0 provides. and XSLT 2.0 and XQuery 1.0 leverage. Done most of the changes. Need to wait and see whether we get the IWorkbenchAdapter for added in M3. Retargeting for 1.0M3. retargeting for 1.0M4 marking this for future depending outcome of XML workbench adaptor changes. mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones. migrating prior 3.1 enhancements for future for further triage and planning. Removed the last of the old XPathNavigator code. |