There are other attributes you might want besides open and closed (style, styleClass, Rendered, disabled, etc.)
This is why I'd want to expand iconProvider to be an attribute provider, so that you could expose any attribute based on the tree node (which could be a POJO). On Tue, 1 Feb 2005 17:12:56 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > This will work for most scenarios I suppose. But consider a scenario > > where the icons depend on the type of a node object but also on other > > attributes like the state of respective node object. That's the scenario > > for using IconProvider as you are able to implement any kind of decision > > logic there. But I think if makes sense to support both ways. You can > > see the IconProvider just as a utility class, a kind of a backing bean > > to obtain your image urls. > > This is where the "-open" and "-closed" suffixes come into play. > These are the only two states that I could imagine would ever apply. > I admit that if there are more, this solution starts to break down. > > Anyways, the component will tell the renderer to render the node and > include information about the node state (that info would remain > independent of the actual node object - same as you have it now.) The > renderer would look for a facet based on the type name (and the > appropriate suffix.) > > This would seem to cover your scenario but maybe I am missing > something. If we still need the IconProvider then this could be > something handled by an alternate renderer perhaps? > > BTW, how are the icons in the example being displayed? I can't figure > it out. I'm assuming they are in the JAR file and you are using a > servlet trick to get at them. What is your secret? > > Regards, > > sean > -- -Heath Borders-Wing [EMAIL PROTECTED]
