You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by "Greg Brown (JIRA)" <ji...@apache.org> on 2010/06/14 00:57:13 UTC
[jira] Resolved: (PIVOT-526) listview and treeview items should
have their own "renderer" property
[ 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.
RE: [jira] Resolved: (PIVOT-526) listview and treeview items should
have their own "renderer" property
Posted by aappddeevv <aa...@verizon.net>.
I'll give this a try and look into TableViewMultiCellRenderer.
Thanks.
-----Original Message-----
From: Greg Brown (JIRA) [mailto:jira@apache.org]
Sent: Sunday, June 13, 2010 6:57 PM
To: dev@pivot.apache.org
Subject: [jira] Resolved: (PIVOT-526) listview and treeview items should
have their own "renderer" property
[
https://issues.apache.org/jira/browse/PIVOT-526?page=com.atlassian.jira.plug
in.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.