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

[Martin Marinschek]

Hi Andy,

> This is exactly what Trinidad's UIXCollection does.

ok, great, than this will fly.

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

I totally agree with you - and finding the component in development
mode sounds reasonable.

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

Sounds nice as well! I have already heard complaints that the ajax
call-length was too large if used in table-cells, especially for
mobile devices.

best regards,

Martin