Hi Karam,
We need to work out what tableData's data structure looks like. The
table component could have all it's properties as as it normally does
(no need to worry about them). However, you're hiding the tableRowGroup
and tableColumn components... so they'll need to be created from the data.
TableRowGroup supports the following properties:
tableDataSorter
onDblClick
onKeyPress
sourceData
aboveColumnFooter
extraFooterHtml
onKeyUp
onMouseUp
extraHeaderHtml
footerText
align
selectMultipleToggleButton
onClick
groupToggleButton
toolTip
onMouseDown
tableDataFilter
multipleColumnFooters
rows
sourceVar
valign
first
onMouseOut
multipleTableColumnFooters
onMouseOver
onMouseMove
emptyDataMsg
selected
collapsed
visible
aboveColumnHeader
onKeyDown
headerText
styleClasses
aboveColumnHeader
onKeyDown
headerText
styleClasses
TableRowGroup also supports these facets:
header
footer
TableColumn supports these properties:
spacerColumn
width
onDblClick
sort
selectedId
onKeyPress
severity
rendered
rowHeader
extraTableFooterHtml
extraFooterHtml
onKeyUp
onMouseUp
styleClass
descending
embeddedActions
height
extraHeaderHtml
align
footerText
scope
style
sortImageURL
onClick
sortIcon
toolTip
onMouseDown
alignKey
tableFooterText
valign
noWrap
onMouseOut
onMouseOver
emptyCell
visible
onMouseOut
onMouseOver
onMouseMove
emptyCell
visible
onKeyDown
headerText
TableColumn defines these facets:
footer
header
tableFooter
So as you can see, the data structure is non-trivial. However, it may
not be as bad as it seems either. If we can agree to not try to
generate TableRowGroup, we can leave its definition in the .jsf file. I
don't think it adds a lot of value to try to eliminate it. As for all
the properties on TableColumn... we could decide to support only a
subset. And/or we could create a naming pattern to cause the factory to
apply the values correctly -- this is made more difficult, however, b/c
there are multiple TableColumns and the values may vary between the
TableColumns.
So we need to know what properties will be supported directly by your
proposed "data" property (if any), and which will require additional
properties in the jsf file delegate. For example:
<sun:table ...>
<sun:dynamicColumnTableRowGroup
data="#{dataPlusPropertiesForAllTableColumns}"
[tableRowGroup properties here] />
</sun:table>
OR:
<sun:table ...>
<sun:dynamicColumnTableRowGroup data="#{dataOnly}"
columnVisible="#{listOfVisibleValuesOneForEachColumn}"
columnSortIcon="#{listOfSortIconValuesOneForEachColumn}"
...
[TableRowGroup properties here] />
</sun:table>
As you can see, the first approach requires a complex data structure
that you must populate. The 2nd approach requires you to create the
same order of complexity, however, it is distributed among multiple List
objects which contain the properties to set for each column.
What do you think?
A 1-off solution wouldn't have to be so generic and could be more
specific to your data and needs. You could use either the "binding"
attribute, or a custom factory (like above), but it would allow to only
do the work you need for your use case.
Ken
Karam Singh Badesha wrote:
> Here is example of how it might look like in .jsf file:
>
> <sun:table data="#{pageSession.tableData}"
>
> .../>
>
> tableData will have all the column tag information and in the .jsf
> page there will be no column tags. Please suggest a way to take care
> of this. It is not really my app specific, it can be used by anyone.
>
> thanks
> Karam
>
> Karam Singh Badesha wrote:
>> Ken,
>> Here is an example of what I am trying to do:
>>
>> Right now in the .jsf page I have to list the column tag with header
>> etc. I have the situation where I have drop down boxes and depending
>> upon different selections, number of columns and column headers could
>> change. And I want the control to be defined in the Resources file,
>> etc number of columns, column headers etc. I am not sure how it will
>> work myself, as the jsf code is changing (when number of columns
>> change). I think when we talked last time, you suggested that I
>> somehow create the table object in java code (handler) and pass it to
>> the page. What do you suggest? Let me know if this is clear or not.
>>
>> thanks
>> Karam
>>
>> Ken Paulsen wrote:
>>>
>>> Hi Karam,
>>>
>>> I can look into doing this... however, after reading the issue more
>>> closely, I need some more information from you. How do you want to
>>> specify the table columns from the page?
>>>
>>> TableColumns typically have children, so they'd also have to be
>>> created. Do you want those to just be staticText? Or do you want
>>> control over what type they are also? Which TableColumn attribute
>>> do you want control over? Perhaps you can provide an example of
>>> what you'd like it to look like in the .jsf file?
>>>
>>> After looking at this more closely, I suspect this may end up being
>>> custom for your needs. However, if I can keep it generic and useful
>>> for others as well, I will.
>>>
>>> Ken
>>>
>>> Karam Singh Badesha wrote:
>>>> Hi Ken,
>>>> Is it possible to get a solution for issue #10 in jsftemplating? I
>>>> really need some solution for this so that create dynamic tables.
>>>> Please let me know.
>>>>
>>>> thanks
>>>> Karam
>