Community
Participate
Working Groups
Build Identifier: 3.4 above In the template view, all the context types are predefined. But we have hundreds of templates and we want them to be grouped/categorized logically (all of our templates are of context type "Java", but it might be messy to put all of them directly under the context type "Java"). It would be much better to navigate/search the templates if the groups can be added by users. The group node should be the children of the context type node. Reproducible: Always
Should be assigned to platform-text-inbox@eclipse.org. Sorry.
(In reply to comment #1) > Should be assigned to platform-text-inbox@eclipse.org. Sorry. Off you go.
For now you could provide your own template contexts which would give you the grouping in the Templates view for free. If we add user-defined grouping support then it should also be honored on the preference page.
(In reply to comment #3) > For now you could provide your own template contexts which would give you the > grouping in the Templates view for free. > > If we add user-defined grouping support then it should also be honored on the > preference page. What does now mean? After my investigation, in eclipse 3.5, it is impossible to provide my own template contexts as no user-defined grouping is allowed.
(In reply to comment #3) > For now you could provide your own template contexts which would give you the > grouping in the Templates view for free. > > If we add user-defined grouping support then it should also be honored on the > preference page. The key is that the group/context should be added/defined by the end user, not via plugin.xml. Can we achieve it now?
>The key is that the group/context should be added/defined by the end user, not >via plugin.xml. Can we achieve it now? No, that's what this enhancement is about ;-) >But we have >hundreds of templates and we want them to be grouped I assumed that by "we" you meant you write a product that contributes those templates. If that's the case you could group them by also contributing new contexts. If that's not the case then you should ask the product that defines hundreds of templates without grouping.
(In reply to comment #6) > >The key is that the group/context should be added/defined by the end user, not > >via plugin.xml. Can we achieve it now? > No, that's what this enhancement is about ;-) > > > >But we have > >hundreds of templates and we want them to be grouped > I assumed that by "we" you meant you write a product that contributes those > templates. If that's the case you could group them by also contributing new > contexts. If that's not the case then you should ask the product that defines > hundreds of templates without grouping. I think the idea that the end user can add context types are not good.The reasons are: 1. The context types are strongly related to the position of the cursor in the editor (E.g. Java editor) and are predefined by every eclipse editor (E.g. Java editor). I.e. if you are in the comment area, you can only insert templates with the comment context type. If you are in other areas, only other templates with corresponding context types can be inserted. So if the context type can be defined by the end user, how does eclipse behave when it imports a template with an UNKNOWN context type? 2. For each context type, there are 2 attributes: id and name. In general, such stuffs with ids cannot be added by the end user in eclipse. I think it might be better to add another field 'group' to class org.eclipse.jface.text.template.Template in plugin org.eclipse.text and other UI related classes should be changed accordingly. In this way, the nodes in the template view will become from two levels (content types and templates) to three levels (content types, groups and templates. Every content type node can have any number of group nodes as its children and every group node can have any number of template nodes as its children and the groups can be added /defined by the end user. Take java editor for example, the context types java, java statement, java type members in current implementation should all belong to one context type java, but their logical groups are different. So the meaning of context type is preserved and the hierarchy in the view might be logically better. I can make this contribution, but I think we need to align the idea first.
(In reply to comment #6) > >The key is that the group/context should be added/defined by the end user, not > >via plugin.xml. Can we achieve it now? > No, that's what this enhancement is about ;-) > > > >But we have > >hundreds of templates and we want them to be grouped > I assumed that by "we" you meant you write a product that contributes those > templates. If that's the case you could group them by also contributing new > contexts. If that's not the case then you should ask the product that defines > hundreds of templates without grouping. The end users may define their own templates and they think their templates should be grouped logically. The group should be defined by themselves. BTW, I am the submitter of this enhancement.
>I think the idea that the end user can add context types are not good. I never said/suggested that the end user should be able to add contexts and of course it's a no go. When I suggested to add contexts then I meant that a PLUG-IN that contributes many templates could also provide some additional contexts to provide a certain level of grouping. So that was just a hint in case that it's your scenario.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
