Hi,
When you say "dynamic generation", do you mean CGLIB or similar? This
approach *does* work (and is used in the project I'm currently working
on) but I didn't mean to imply that with my comment.
To expand on my example below, if a table of Person objects has a column
containing:
<t:dataTable var="currPerson" ....>
<t:outputText value="#{currPerson.name}"/>
then this can be converted to be a table of PersonHandler objects, and
the jsp can be updated to:
<t:dataTable var="currPersonHandler" ....>
<t:outputText value="#{currPersonHandler.person.name}"/>
...
<h:commandLink action="#{currPersonHandler.doSomething}"/>
All that is needed is for the PersonHandler objects to have a
getPerson() method. No "dynamic generation" required. And the
doSomething method obviously knows which Person to modify - the Person
it wraps.
Regards,
Simon
fastbob wrote:
Hmmm. I think you're spot on with your comment about putting the
functionality into the row object itself. That's what I was trying to do
when I erroneously attempted to bind to the dataTable var. Each row object
would be responsible for generating the appropriate components. But it
sounds like the row object can only be accessed through its parent
dataTable, which I suppose makes some sense.
It finally dawned on me that I need to deal with the dynamic generation at
two points - the rendering of the HTML and when the values are posted back
to the server. The latter I think I can deal with, but the former has me
scratching my head. It seems like I'll need to generate the dynamic
components at the same time I initialize the dataTable list (perhaps in a
map), and then refer to those components in the column definitions.
fastbob
Simon Kitching-3 wrote:
fastbob wrote:
Is there a preferred JSF pattern for communicating user selection of a
dataTable row back to the server? I've found a number of somewhat crufty
methods (such as on BalusC), but unless I've missed something, none seem
particularly attractive other than f:attribute. But perhaps that's just
the
nature of the beast. Any suggestions?
Generally when processing a row the nicest solution is to build any
functionality needed onto the row object itself. Suppose the model is
normally a list of Person objects but some logic is needed to manipulate
a particular person then the model can be changed to a list of
PersonHandler objects each of which has a "person" property. In this
case, there is no "communication of the user selection" required; the
method is invoked *on* the selected object.
An alternative is to set the "binding" attribute on the t:dataTable
object, then the callback method that is invoked can call the getRowData
method on the datatable to find the row "currently being operated on".
It's not so elegant but does work fine.
I think that if you write the commandLink to invoke an ActionListener
rather than an action method then the event might also have the
appropriate row info but am not sure of the details here.
Regards,
Simon
