[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-1433) Tag libraries tree node on Web Projects view shouldn't use only file name to render taglibrary node text label

[ http://jira.jboss.com/jira/browse/JBIDE-1433?page=comments#action_12401210 ] Viacheslav Kabanovich commented on JBIDE-1433: ---------------------------------------------- Label Decorations preference page.jpg Our contribution to navigator contains objects implementing XModelObject interface, which are finely adjusted with meta data. This provides for an easy way to let users of Studio to customize presentation of objects in navigators. Usually, to build label text, we use the value of object attribute that identifies it in the best way, and restrain from encumbering the label with values of other attributes. But other object attributes may be quite useful in customizing the label, just user needs an instrument to help him adjust it as he likes. Presentation of taglib node is a good example, but I think it is not the only case where customizing label may be needed. We have trees for tld, web.xml, faces-config, tiles, seam components, struts-config, hibernate, etc. As just one more case, many xml nodes have attribute 'display-name', and while we cannot rely upon it in building label text, as most often it is left empty; some users who painstakingly fill presentation-like attributes might wish to see them it tree instead of 'name'. I had seen two ways to implement this functionality: either add some new sections to internal *.meta files, or do it in the open Eclipse-style way that would depend on internal meta minimally. I did not mean to create some obscure xml language, but included to extension point definition what seemed necessary. 1) partition. Preference page contains tree with customizable decorations, the first level is partition to group together decorations for objects used in the same kind of file (seems most natural grouping principal to me); the second level - contains object decorations. 2) name. Just name of decoration to be shown in preference page. 3) entities The point of connection to meta data, - we need to list names of objects declared in meta data for which this decoration is relevant. 4) defaultValue The default value of the format to be used to build object label. For TLD file object, it looks like a good solution to addby default 'shortname' attribute to the file name. 5) <variable> As in CVS and SVN preferences pages for text decoration, there is a trivial formatting language "text1{var1}text2{var2}" We need to specify variables and define how they work. In CVS, the variety of objects is rather limited and they can be satisfied with several common variables. In our case, set of variables depends on object, of which we have a lot. Like in CVS, I decided that variable needs name and description. User does not need to remember variables that can be used to decorate text presentation, so 'Add Variable...' command is used. (see Select Variable for formatting label.jpg) 6) <example> Is not it good for a user to see immediately the result of his modifications to the format of a selected object decoration. Here, we have to provide a test object populated with values of attributes used as variables. That is all about the xml structure. About enablement. I have thought about making tree with decorations check-box tree with check boxes for enabling/disabling each separate rule or entire partition. I postponed that because now implemented decorations do not do anything especial by default, and algorithm for applying them is quite fast. About making this extension point *internal*. It can be internal, but also we can make it public by providing in docs information of object entities and their attributes, that is by opening as needed interface to our internal model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira