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@apache.org>
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.

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?

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

best regards,

Martin

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces