Re: [jsr-314-open-mirror] [jsr-314-open] Ajax inside a DataTable
Perhaps one reason why I had a mental block on the UIData being a
valid execute/render target is because I was always hoping that we could avoid the
findComponent() calls altogether and instead just use basic string manipulation to produce
relative ids. (We would use findComponent() in development mode just to verify that the
specified id was valid.) All of this component tree searching seems expensive,
particularly when stamping out <f:ajax> content repeatedly (eg. in a data table).
Sounds very good to me. I'm not a fan of findComponent calls either.
Regarding my initial mail, datatable is found correct but as it's being rendered as
well as the f:ajax, getClientId implementation of UIData appends the current rowIndex, in
the end each f:ajax in every row renders something like render="table:0",
render="table:1" whereas users expect render="table" since they want
to update the datatable. This happens both with mojarra 2and myfaces 2.
So to confirm, what have we decided? Should I create implementation tickets for
Martin's suggestion on getContainerClientId() getClientId() idea to solve this?
Cagatay
On May 19, 2010, at 11:40 PM, Andy Schwartz wrote:
Perhaps one reason why I had a mental block on the UIData being a
valid execute/render target is because I was always hoping that we could avoid the
findComponent() calls altogether and instead just use basic string manipulation to produce
relative ids. (We would use findComponent() in development mode just to verify that the
specified id was valid.) All of this component tree searching seems expensive,
particularly when stamping out <f:ajax> content repeatedly (eg. in a data table).
>
> This ties into another related topic that we left unfinished in JSF 2.0... Ideally
we shouldn't need to send execute/render ids to the client at all as:
>
> 1. These ids can be expensive to produce (require findComponent() calls)
> 2. These ids bloat the size of our rendered HTML content.
>
> For 2.1 perhaps we should consider adding a mechanism by which Behaviors can hook
into the lifecycle early enough to allow AjaxBehavior to set up the execute/render ids on
the PartialViewContext after the postback occurs. This would be more efficient than
requiring AjaxBehavior to aggressively render out the execute/render lists each time it is
asked for a script. (Again, this could be especially important in the stamping case.)