On 5/19/10 6:02 PM, Martin Marinschek wrote:
> 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
> 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
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
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
I think we can regard this as an implementation bug - Catagay, can
open issues for Mojarra and MyFaces?