We need to fol,low up with the JSF spec because:
1) The RI does not implement the behavior you would expect from the
JavaDoc because calling getClientId() on a component with a null id
causes the id of the component to be set as a side-effect. The expected
result would be that the id of the component would not be set in this case
2) The behavior implied by the Javadoc (and the one I believe that
MyFaces does and Trinidad tried to implement) is not useful. I see no
reason why it is preferable that the clientId of a not agree with the
component's id just so that the component's id can sometimes be null.
The only advantage of supporting a null id is lower memory usage for
dynamically created components.
The other insidious side-effect of getId() being allowed to return null
is that this caused problems with the JSF RI not having stable
clientIds. This led the RI to impement clientId caching. The RI's
implementation of clientId caching:
1) Requires special behavior on components that want to work with
components that inherit from the RI's UIComponentBase
2) The RI doesn't correctly clear its caches in cases when it should
(the id of a NamingContainer changes, thus affecting the clientIds of
its descendants or a component is moved between NamingContainers,
affecting both its and its descendants clientIds)
So, for JSF 2.1 we should also address clientId caching and at the very
least have real apis for clearing the caches and have the spec actually
define the required behavior.
-- Blake Sullivan
Matthias Wessendorf said the following On 2/9/2010 12:54 AM PT:
Hi,
Blake committed an interesting patch to Trinidad:
http://bit.ly/dtghOs
I see that MyFaces can actually return NULL on getId(), however the
MyFaces implementation
goes ahead and creates the ID if getClientId(facesCtx) is called AND!
the getId() returns null.
So, why not directly ensuring that getId() can't return null ?
Checking the JavaDoc of getClientId(FacesCtx), I see that MyFaces is
doing what is required.
But does that really make sense?
-Matthias
