Hey Cagatay - On 5/19/10 4:20 AM, Cagatay Civici 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 to components within the same row. There is a way out of this... You can specify an absolute id by prefixing the id with ":". At that point the id starts from the root of the component tree and you can specify any number of colon-separated segments to descend into each naming container. (This matches the syntax used by findComponent().) Of course, specifying absolute paths is at a minimum difficult, and in some cases, just plain impossible to do (eg. when reusing content across multiple pages). In Trinidad we use a double-colon prefix ("::") to reference up one level in the NamingContainer hierarchy - similar to ".." in file system paths. I suggested exposing this when we were working on the <f:ajax> spec, but this topic got shelved until 2.1. Dan has captured some of our thinking here: http://seamframework.org/Documentation/JSF21#H-ReevaluateComponentReferen... More here: http://seamframework.org/Documentation/JSFEnhancementComponentReferencing Oh, and... for the particular use case that you describe above, I think that it is very important that the JSF implementations give some warning when a referenced component is not found, at least when running in development project stage. Not sure which implementation you are testing, but it might make sense to log bugs against MyFaces/Mojarra if this is failing silently in development mode. Andy

Hi Martin I just want to note a side effect of this change: getContainerClientId() was introduced in jsf 1.2, but code written in jsf 1.1 uses getClientId(). If we apply this change, all libraries for jsf 1.2 needs to be updated. I think we can do this for jsf 2.0 but my question is if we should apply this change on jsf 1.2 branch. Components written for jsf 1.1 that extends from UIData will not work correctly with this change. regards, Leonardo 2010/5/19 Martin Marinschek <mmarinschek(a)apache.org&gt;

On 5/19/10 6:02 PM, Martin Marinschek wrote: 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. 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

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

Hi Added issue on myfaces: MYFACES-2744 UIData.getClientId() should not append rowIndex, instead use UIData.getContainerClientId() I'll solve this one before myfaces core 2.0.1 release. regards, Leonardo Uribe