Bugzilla – Full Text Bug Listing
| Summary: | Provide more specific XSL Awarness and groupings for Outline/Model views. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | arne anka <eclipse-bugs> | ||||
| Component: | wst.xsl | Assignee: | David Carver <d_a_carver> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Doug <doug.satchwell> | ||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | alex.blewitt, d_a_carver, thatnitind, wellington.bengtson | ||||
| Version: | unspecified | Keywords: | helpwanted | ||||
| Target Milestone: | 3.2 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
arne anka
Not sure if this belongs in XSL tools or somewhere else, but probably not in common. Right now we just inherrit what we get from the XML Editor. One idea I've been toying around with is making a XSLT aware Outline view, that would break up the content a bit more. So that it was easier to see imports, includes, templates (match) and templates (name), as well as variables and parameters. Unfortunately I haven't had time to investigate this. Currently the XML editor doesn't allow sorting of the elements either so this is why we don't have this ability currently. The XSLT-aware outline view is a good idea. We have the model, all we need to do is display it. We just need to create IWorkbenchAdapter's for each XSL object. And then display: - imports/includes - global variables - templates that would probably be enough? (In reply to comment #2) > Right now we just inherrit what we get from the XML Editor. One idea I've > been toying around with is making a XSLT aware Outline view, that would break > up the content a bit more. So that it was easier to see imports, includes, > templates (match) and templates (name), as well as variables and parameters. > Unfortunately I haven't had time to investigate this. > > Currently the XML editor doesn't allow sorting of the elements either so this > is why we don't have this ability currently. Would adding it in the XML Editor cause any problems for XSLT? It would end up sorting the XSL categories as well according to their labels. It depends, it would need to be handled probably the way the JDT outline handles sorting there. Personally I view the outline being enhanced with a more programming look and feel (sorta like JDT's look a feel, but for XSL specific templates, and imports/includes). Opened bug 246024 for general refactoring of the standard XML outline configuration. i want to work on this issue. do you know which packages should i check out to have the XML Outline view working? i would like to extend it to add the support for the features below like imports / includes, etc. Wellington, you might want to take a look at the Stylesheet view. (Just do CTRL+3 and type Stylesheet) to view it. In order to get the necessary code out to work with implementing a XSL particular view, you should check out the XSL team project set file. You can find the necessary link on the XSL Tools wiki page. http://wiki.eclipse.org/XSLT_Project Sorry for the delay in responding. hi, thx for the answer... I found out how to build the plugin and i started to work on the outline view, i hope that in a few time i will be posting here a patch Wellington, any progress with this. I'm tenatively targeting this as an item for 3.2. Assigning inbox items to triaged since these have all be triaged. Need to convert the Stylesheet view into an XSLT specific Outline view. The first step in this was to provide a more XSL aware view. The outline view now when working with XSL content will provide some more specific icons for XSL. This helps in the view to identify the templates, xsl statements, and the xml elements that are embedded in the stylesheet. I've checked the current work into head. Grouping blocks: * Imports * Attribute sets/variables * Templates I think if you group them, you don't need to have the tag type in the outline. For example, currently: +stylesheet - import href=../fo/docbook.xsl - import href=../highlighting/common.xsl - template match=row - template name=calsTable If you group them: + + Imports - href=../fo/docbook.xsl - href=../highlighting/common.xsl + Templates - match=row - name=calsTable Arguably, you could do some processing on a per-type basis as well; for 'templates' you could just show the name or match element, and for imports, you could just show the value of href: + + Imports - ../fo/docbook.xsl - ../highlighting/common.xsl + Attribute sets - shade.verbatim.style + Templates - row - calsTable You might need to find a way of (visually) representing the difference between a name and a match, because (a) I don't think it makes sense to subdivide them, and (b) you (probably) need to keep the ordering, which if you put the 'named' templates in one place and 'match' in another one might get lost. 'twould also be good to have something to filter out comments from the outline view; can't really see how having those in place would be useful. Thanks for the suggestions Alex, it's going along my line of thinking as well. One question is should the different template modes be distinguished as well. In XSL you can have mode as well as a priority for a particular template. Created attachment 149373 [details]
Stylesheet Model view and enhanced outline view
Here is a proposed modification to handle the two scenarios described. First, I've cleaned up the unfinished Stylesheet View and renamed it to the Stylesheet Model. Since it is backed by the XSLT Model it contains much of the information we needed for grouping the items, plus will allow for further exploration into the included and imported stylesheets as well.
I've enhanced the outline view, so that information on regarding named templates and match templates are different. If a template has a Mode in the outline view, it is displayed in the tool tip when you hover over it.
I'll synch these modifications up later today. The stylesheet view can be brought up by going to Windows->Show Views->Other->XML
updated the title of this bug to better reflect the actual work taking place. Resolving, this will be available in 3.2M3 (xsl tools 1.1M3). |