Well, I hope the subject is enough to drive your imagination.
The problem is that parent component would have to render header facets
from custom:column children at one place and their body content at another.
And even inside a ui:repeat.
Actually I nearly managed to do the last thing with current JSF 2.0, but
if I do
<table><tbody>
<ui:repeat var="row" value=#{compositeComponent.attrs.value}>
<r>
<composite:renderUsingPageChildren/>
</r>
</ui:repeat>
</tbody></table>
in the custom:table,
then I have a lot of problems if custom:columns bodies happen to contain input components,
the ids are just not generated properly. Is this a bug or it is intended behavior with rendersUPC
or insertFacet? I found that if I wrap <composite:renderUsingPageChildren/> with h:panelGroup id="panel" I get the right <span 0d="panel:1,2..."> id's but the spans are placed outside the rest of the table!
And another question: if I have two components coupled like these, wouldn't it be nice
to able able to access the attributes of the custom:table component from custom:column?
The straight example I can think of is h:column accessing value of h:dataTable,
but there probably are some really meaningful ones.
I am asking all these questions because I'm trying to implement an adjustable table component where user can add or hide some or most of the columns (and I more or less succeeded but the code is rather ugly).
usually there are 200 rows and up to 50 possible columns, 5 of them are usually necessary
and then 2-3 of the other 45 may be of interest to the user.
I used to implement this with a c:for-each running along all the 50 column types
and then using render attribute to actually decide whether to render the column.
This was just hardcoded, then I switched to facelets components, interface became
nearly ideal but no parameter checking. Then I tried to switch to JSF 2.0 composite components
but there are much more restrictions on what one can do. rendersUsingPageChildren does
not seem to be equivalent to ui:insert (I wish we'll had a clear documentation on these soon),
if one places into h:dataTable a composite component even containing ui:column as a top element, it does not recoognized (well, I am not 100% sure ).
And a major issue is - the viewstate is just HUGE!
That's why now I switched to ui:repeat + ui:repeat implementation, I get like 50 times smaller
view state. (it's possible to iterate only through the shown columns then in contrast to c:forEach
which is the only option for ui:column). This makes me happy, cause JSF 2.0 helped to produce something very efficient.
I wish I knew some technique to inspect the viewstate though.
(facelets debug does not help much here, I was thinking about placing a breakpoint
at the place when the viewstate gets unpacked, but haven't tried that.
May be you have some favorite trick here?)
Actually I'm still puzzled by the view state growth because only one or two of the columns
contained input components, and if it is just output why do you need to save a lot of viewstate?
Well, sorry for such a long story. I guess this component gets developed by 3-4 month already..
[Message sent by forum member 'nzinoviev' (nzinoviev)]
http://forums.java.net/jive/thread.jspa?messageID=331389