Re: [core] UIComponentBase.getId() can return null
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
[core] UIComponentBase.getId() can return null
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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] UIComponentBase.getId() can return null
Hi, So the difference between getId() and getClientId() is that the last one generates the Id if necessary, am I right? From my point of view getId() is the getter for the id property which can be set with setId(). However, there is no method setClientId(). So I think the sence is that getId() returns non-null if the user assigned an id to the component and null otherwise, whereas getClientId() always returns a valid id, because it generates one if the component has no assigned id. So you are able to check if the user assigned an id to the component if the result of getId() is non-null. Nevertheless I don't know if that makes a lot of sence... Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf