> I'm not talking about open/closed state but about application-specific > states like a node which is locked renders as a red folder, a node which > is not locked renders as a green folder. This can get quite complex when > you try to do it using your facet logic.
Well you have foiled my plans. OK that is a reasonable possibility that you might have some application specific state. The end user could subclass TreeNode to store this state then right? > I also don't think we need an alternate renderer I can see your point on that. Let me think more about your IconProvider now that I better understand your use case. I would like to think about how this icon provider would really be different from a renderer (I haven't concluded either way yet.) If its not really adding anything more than a renderer could, then we would probably want to shy away from introducing something that can already be handled. Something to think about would be if you have a "locked" node, then is it really sufficient to just have a "locked" icon. How would you stop the user from opening it. The icon provider is just providing the icon. The renderer would be doing the decoding and could handle more appropriately. I like your solution. I just need to convince myself that its appropriate to use this instead of a renderer. sean
