Hi, sorry for the confusion in my write ...
> 1) Adding support for a "alternateNodeColor" style to TerraTreeViewSkin is > probably a good idea, as it will be necessary to support a TreeTable > component. That would be a style that you'd set on your tree view that > would cause the background color of each node to alternate, just like it > does in TerraTableViewSkin. Right. > 2) Creating more complex logic as to how to paint each node based on > heuristics that you define could be done in a custom renderer. The renderer > would be set on the tree view using setNodeRenderer() and would be > responsible for laying out and painting the contents of each node. In > absence of the "alternateNodeColor" style on the skin, you could get the > alternating node colors to *sort of* work using this custom renderer > approach -- the renderer is only responsible for the content area of each > node, not the checkbox area of expand/collapse control area. Perfect. Todd understands what I write :-) ... I'm sure Greg too but he makes me some questions to see how little I know Pivot :-) . Don't worry, I'm joking here. >> write the logic in the related renderer (fixed for the component), and >>> inside it choose what / how to do the paint ... ok. >> >> What do you mean by "fixed for the component"? Fixed here means that it's always the same, and i can't for example changing it via a configuration option (for example set as a style or other attribute in a wtkx file). So I have to handle all the custom logic in the renderer for the component. The best here could be to have the renderer call some user defined class or methods only for some calculations, row by row ... but we have to see the performances impact here. Or maybe a simpler way here could be to derive a subclass in application-specific code and write a custom implementation of the renderer. > I'm not sure you could actually do it using the renderer alone - the renderer > isn't given the index of the node within the tree view, so it wouldn't know > which rows were "even" and which were "odd". This could be a problem, but maybe with some (future ?) API refining this could become available. Real use case: for a my web application some time ago I had some logic to calculate the row color (of any row of an HTML table body), where, depending on the type of the data contained in the Model for the row (for example normal data, or row of totals) i used a different css style (for example background color for the row, and bold text in some cases). In some cases this could be useful to have (and not only for TreeTables, like seen before). Do you like the idea ? Thanks, Sandro
