Community
Participate
Working Groups
It would be very nice if an action could be added to the xml ouline view to to hide the comments. This will increase the usability of the outline.
To take it a step further, a generic filter mechanism would be nice as well. Though I agree the most important is hiding comments...as the outline/tree views are fairly unreadable/usable with documents with a ton of comments. See Task, Package Explorer, Problem views for similar filter feature.
That kind of filtering would be handy, but it would need to be generic and yet still adapt to the kind of file being edited. It's a great idea, but we don't have people to work on this just now. We would accept high quality patches, though.
mass reassignment of my bugs to xml-inbox
nitin, this sounds like a bug day candidate...and I would have to agree, being able to hide the comments would make the outline view much more useful when dealing with heavily commented xml files.
I would like to work on this. I'm a GSoC student for Eclipse this year and this is a good place to start.
Created attachment 158575 [details] Patch to add the User Defined pattern Filter for sse and different Named Filters for content types patch to add a User Defined Pattern Filter at UI Level. JavaElementFilter extension pt of JDT is further used to add named Filters for different content types like html, jsp and XML. Currently I have added CDATA, Comments and Processing Instruction Named Filter for XML and html/JSP has Import Directive and Font Style Filter. More Filters can be added at any point for any content type.
(In reply to comment #6) > Created an attachment (id=158575) [details] > Patch to add the User Defined pattern Filter for sse and different Named > Filters for content types > > patch to add a User Defined Pattern Filter at UI Level. JavaElementFilter > extension pt of JDT is further used to add named Filters for different content > types like html, jsp and XML. Currently I have added CDATA, Comments and > Processing Instruction Named Filter for XML and html/JSP has Import Directive > and Font Style Filter. More Filters can be added at any point for any content > type. My concern with this is are we tying this in anyway to having a dependency on JDT that will require JDT be installed? Particularly the requirement with JavaElementFilter. For the JSP editor this might be fine, but I'd hope that SSE/HTML/XML, etc can be kept clean.
(In reply to comment #7) > (In reply to comment #6) > > Created an attachment (id=158575) [details] [details] > > Patch to add the User Defined pattern Filter for sse and different Named > > Filters for content types > > > > patch to add a User Defined Pattern Filter at UI Level. JavaElementFilter > > extension pt of JDT is further used to add named Filters for different content > > types like html, jsp and XML. Currently I have added CDATA, Comments and > > Processing Instruction Named Filter for XML and html/JSP has Import Directive > > and Font Style Filter. More Filters can be added at any point for any content > > type. > > My concern with this is are we tying this in anyway to having a dependency on > JDT that will require JDT be installed? Particularly the requirement with > JavaElementFilter. For the JSP editor this might be fine, but I'd hope that > SSE/HTML/XML, etc can be kept clean. Hi, Sarika. I agree with Dave. I'd prefer if we didn't add a dependency on the JDT to support outline filtering. Is it possible to revise the patch to remove this?
Created attachment 158676 [details] Patch to add the User Defined pattern Filter for sse and different Named Filters for content types Removed the jdt dependency from sse,xml and html plugins. Added some new classes in SSE to achieve this.
Small comments for the next iteration of the patch: we usually don't need to label a class SSE* as it's already in our package namespace, and even then we've tended to use "Structured" as the prefix if it's in sse.core or sse.ui. Also, are those extra keys in the sse.ui plugin.properties file? +#Filter Support + +HideImportDeclaration.label= Import declarations +HideImportDeclaration.description= Hides all import declarations
Created attachment 159755 [details] Refined Patch Refactored few class names and removed the extra plugin property from sse.ui as suggested in review comment.
We'll try to take a look at this for 3.3.
Hi Sarika, one of the things I think that will need to be fixed is how many things are in API packages. Can you filter down what we're actually going to offer as API classes (if any) otherwise, these need to be in internal packages.
Created attachment 172315 [details] Moved the filters to be used in plugin.xml out of internal package Synched up the code with latest code and moved the filters out of internal package.
Hey, Sarika. I think we're almost there. * I think what is exactly API still needs to be identified. I don't think any of these new classes really need to be exposed as API. Right now, there are a lot of things exposed as API. In particular, it seems like the entire org.eclipse.wst.sse.ui.filters package could be internal. Also, I don't think the CustomFilterAction or CustomFilterActionContributionItem need to be in an API package. * For the extension point, is the "pattern" attribute necessary? The documentation for it says it shouldn't be used (and we haven't even released it yet) * We may want to add a Comment filter for HTML and JSPs. CSS may benefit from a comment filter as well. * Something nitpicky, but I would probably have a protected method like getOutlineFilterTarget() and override it instead of having the setter, then you can just invoke the method instead. * It looks like some classes were based on work from the JDT. It might be worth commenting that in the Javadoc and also cleanup comments like "since 2.0" because it's brand new for Source Editing. * I also think we need an icon. I think there's a standard one used by the Problems view and JDT's outline. Thanks for your continued work on this!
Is there a particular reason we are using Actions instead of Commands and Handlers as well as the menu ui extension point?
What's being made available is a mechanism for contributing the filters themselves. The UI for controlling them is fixed as coming from the ContentOutlineConfiguration, which doesn't really demand the abstractions of commands and handlers. Apart from the keybindings this would allow, is there a reason to favor it?
(In reply to comment #17) > What's being made available is a mechanism for contributing the filters > themselves. The UI for controlling them is fixed as coming from the > ContentOutlineConfiguration, which doesn't really demand the abstractions of > commands and handlers. Apart from the keybindings this would allow, is there a > reason to favor it? The action framework is not the recommended way forward. It doesn't allow adopters much flexibility in providing their own implementations and handlers. The commands, handlers, and menui is more more adopter friendly approach. It also separates the implementation much better as well. It's the reason we did the big migration a couple of years ago for the other portions to allow adopters more flexibility.
Created attachment 182837 [details] Patch to add the new Filter using Command Handler Framework Hi Nick, The attached patch takes care of the following review comments : 1) converted new action to command handler framework 2) moved the filiet classes to internal 3) removed JDT legacy comments 4) changed setter to overriding getters 5) removed unused pattern from schema 6) added the filter icon
Hi Sarika, Thanks for the updates. I've got a few things. 1. Can this be refactored so that we don't expose the treeViewer from the ConfigurableContentOutlinePage and the preference store from the ContentOutlineConfiguration? The one I'm more concerned about is exposing the treeViewer. 2. We need to make sure that the filters menu is only added to the menu when our ConfigurableContentOutlinePage is used (right now, our Filters shows up for the Java or Manifest outlines). 3. The extension point name may be better as "Outline Filters". 4. There are still references to 'org.eclipse.jdt.ui.javaElementFilters" extension point.' These kinds of things need to be cleaned up. And there are assert messages that log the extension-point "org.eclipse.jdt.ui.javaElementFilters" 5. OutlineFilterMessages.properties's filterCreationError_message looks like it got mangled a bit. 6. I don't think we need the Font Style's filter for HTML. These can all be removed through a custom filter and also a lot of these are fairly important semantically to the document and you'd lose a lot of elements if you just wanted to remove one of them. It also looks like a string got mangled for it ("HideFontStyle.description=Hides Font Style TagsproposalCategory.htmlTags=HTML Tag Proposals"). 7. Finally, the icon needs to be attached separately from the patch. If it's included with the patch, it will actually prevent me from applying it.
Created attachment 183247 [details] Filter icon
Created attachment 183248 [details] Custom Handler Patch with property tester
Hi Nick, I have added a property tester for outline page instance verification and refactored the Handler method inside configuration class .Font filter has been removed and the jdt.ui references have been cleaned up. I have added the Filter icon seperately and renamed the extn to "Outline Filters".
Thanks, Sarika. I've checked in your changes with some minor alternations and consolidations (e.g., removed Node references in sse.ui).
Verified against I-3.3.0-20110303220333.
