This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This is motivated by use of looks in projects. I am not sure it all of it applies to looks in general. Currently we can register looks for classes and for mime types. Some of the looks for visualization of project do not represent any real objects, they visualize "virtual" objects and do not need any data (they get the data from elsewhere in the project). Examples of these are Sources, Resources, Output in the projects infrastructure. Other examples need to be created in web module or j2ee modules (Document Base, Web Components, EJBs, etc.). It is now necessary to define empty marker classes to which the looks are then registered. I propose to define a new look selector that would allow to define looks for instances of a given class (e.g. java.lang.String or some marker class defined by looks module).
It will be useful also for categorization nodes (Fields, Methods, ...)
Can easily be done by some external code, e.g. Projects API module, without help from looks.jar. Define some marker class with a name field and a simple factory, and register a metalook for this class. Anyway you need to specify the child objects so you will need some additional machinery for that. IMHO should not be in base Looks API, though if it used consistently from many modules (not just projects-api-based) and code sharing is desired it could be added to some util module in the future.
Jesse, that's clearly a possibility. I discussed this with Hrebejk and he thought that this may use useful more generally. He is the owner of looks api so I will let him decide. As for the child objects you are right -- I using the fact that projects module puts the Project instance into a lookup of substitute.
Marking as low priority enhancement. Some kind of support might be added later, when we see that it is really necessary. For now it sould be enough to create some class representing a group. Which will hold name of the group and some data from parent. (Holding data from parent is usaually necessary anyway to be able to produce child objects etc.) And create a subclass of NamespaceSelector whit namesFor() method overriden to return the name of the group. The code which follows demostrates this feature on parsed HAT heap. The groups will represent Classes and Roots on heap. It is possible to registrate looks for the groups using XML layer (folder: Looks/hat/Groups). The LookSelector would look like: public class GroupSelector extends NamespaceSelector { public static final LookSelector INSTANCE = new GroupSelector(); private static final String PREFIX = "Looks/hat/Group/"; /** Creates a new instance of HeapSelector */ public GroupSelector() { super( PREFIX ); } public Enumeration namesFor( Object representedObject ) { return new SingletonEnumeration( ((Group)representedObject).getName() ); } } The Group class: public class Group { public static final String ROOTS = "ROOTS"; public static final String CLASSES = "CLASSES"; private Snapshot snapshot; private String name; /** Creates a new instance of Group */ private Group( String name, Snapshot snapshot ) { this.name = name; this.snapshot = snapshot; } // Creation methods public static Group getClasses( Snapshot snapshot ) { return new Group( CLASSES, snapshot ); } public static Group getRoots( Snapshot snapshot ) { return new Group( ROOTS, snapshot ); } // Properties public String getName() { return name; } public Snapshot getSnapshot() { return snapshot; } }
Changing target milestone on all Looks issues to future
x