[jsr-314-open-mirror] [jsr-314-open] Ajax inside a DataTable

[Cagatay Civici]

> 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.)