[
https://issues.apache.org/jira/browse/PIVOT-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown resolved PIVOT-526.
------------------------------
Resolution: Not A Problem
Renderers are used to "rubber stamp" content and generally use the same (or
similar) format for each item. If you find that you need a different format for
each item, you may be better off using a container rather than a data-driven
component:
ListView -> vertical BoxPane
TableView -> TablePane
TreeView -> nested Rollups
If you really need to use a data-driven component to present your data, you
might want to take an approach similar to what we do in
TableViewMultiCellRenderer.
> listview and treeview items should have their own "renderer" property
> ---------------------------------------------------------------------
>
> Key: PIVOT-526
> URL: https://issues.apache.org/jira/browse/PIVOT-526
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
> Reporter: Appddevvv
>
> I was trying to change the way the selection looks when an item is selected
> (versus non-selected). This was to provide additional annotations for the
> selected item (for me, I wanted to change the highlighted box color,
> highlight box size, and text font would change based on selection status). I
> can do this if I write a more complex renderer with the logic built into it,
> or I could break this logic out and when the item is selected us the renderer
> from my basket of renderers based on state e.g. the selected state. I am a
> total flub at writing renderers and gave up on this for today but this was my
> thought around controls with items in them.
> I don't think anyone is going be perish without this, but it does allow
> clients of the library to provide their own renders to reflect their own
> state versus a single renderer that has a bunch of switches in it to reflect
> state. This makes per-item rendering easier to write...even in the existing
> pivot code actually. You could probably factor out a subclass to handle
> common rendering for controls with items in them.
> You can mark this one for the future. I'm not sure I am using the word
> renderer correctly here. Its' whatever "<insert class name here>" is used to
> draw the individual items. I'm not sure this is the skin or the renderer.
> If a default renderer is used when none is present on the item, you would
> fall back into the current approach. Hence, the existing API does not need to
> change at all but the "item" api would be enhanced.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
