> 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
