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

This is exactly what Trinidad's UIXCollection does.

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