> > > expandAll and collapseAll are not implemented because it's not hard to do > in > > application code. A simple tree traversal with calls to setExpanded() > would > > do the trick. With only operating on the selection, it's even easier, > > because you just iterate over the selected paths (getSelectedPaths()). > Ok, I've looked at the code and this is right (no doubt :-) ), but i > think that some common operations like these should be handled ... if > not in the component in a utility class. I can make them, what do you > think ? >
I've had such occasions (not these exact ones, but my own app-specific cases) in the suite of Pivot apps that I've written, and I think the best solution is to write a set of utility methods in your application to handle the common things that you need (re-use code, but make it local to your app). Adding small convenience methods to the platform for every app that needs them will just bloat the platform, since every app's needs are different. > A last thing: > for the background coloring of each row, do you think it's better to > fire a dedicated event (by default not intercepted) and leave the > custom code to do the logic, or the same but set as a (style) > property, without firing events ? > What events are you picturing? Alternating row color has to do with how the skin paints - it doesn't seem the kind of thing for which events play a role. Since it's related to paint, it fits the bill of a style property.
