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

[Andy Schwartz]

On 5/19/10 6:02 PM, Martin Marinschek wrote:
> Hi Andy,
>
>   
>> Ids specified by <f:ajax> are relative to containing component - in this
>> case, relative to the <h:commandButton>.    This makes is easy to specify
>> execute/render ids for components within the same NamingContainer (which is
>> by far the most common case).  In the case of iterating components like
>> <h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
>> components within the same row.
>>     
>
> Yes, but what Cagatay totally correctly refers to is that the table is
> certainly not in a row - how can the table be in a row of itself? This
> is semantical nonsense.
>   

Ugh, yes, of course.  For a moment there it slipped my mind that the 
UIData component is indeed found as part of the relative id search.  I 
was thinking that only the stamped components would be considered valid 
execute/render targets when a row index is set.  But, since we spec'ed 
findComponent() semantics for execute/render, the UIData would indeed be 
found, and, yes, we should use the correct client id.

> We should never include the row-index in the client-id of the table
> itself. For this, we need to revise the client-id generation
> algorithm.
>
> Without actually having tried it, I think that it is easy to do so, as
> we have a UIComponentBase.getContainerClientId() to create the
> client-id of the children - when this method is called, we append the
> row-index, if getClientId() itself is called, we don´t. Does this
> sound reasonable to you guys?
>   

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

Andy

> I think we can regard this as an implementation bug - Catagay, can you
> open issues for Mojarra and MyFaces?
>
> best regards,
>
> Martin
>
>