I am wondering if this is a bug or planned with UIXComponentBase:
I was noticing that my custom component that extended CoreCommandLink
stopped working after a partial update. When trying to figure out why,
I noticed that the ID of the link changed between rendering and
therefore the decode no longer worked.
On first page rendering, the link ID was _id44. During decode, it was
still _id44. During encode, it was _id108. It failed partial update
because the ID changed, and therefore all further decodes failed since
the client was now out of sync from the server.
In UIComponentBase.getClientId, if the getId() returns null, a new ID
is created and then setId is called. UIXComponentBase never calls
setId, but instead caches it in a "_genId" property using the
FacesBean.
Therefore, anything extending UIComponentBase and has a generated ID
will never have its ID change between requests on the same view.
However, it seems that UIXComponentBase does not guarantee that a
component with a generated ID will have a consistent ID.
Here is my code:
<tr:panelLabelAndMessage
label="Test help">
<tr:inputText id="testHelp" value="#{testHelpText}"
simple="true" />
<f:facet name="end">
<cw:helpIcon for="testHelp"
messageId="test_help" />
</f:facet>
</tr:panelLabelAndMessage>
The cw:helpIcon extends CoreCommandLink
If I give the helpIcon a hard coded ID, it works fine.
Is this a bug, a shortcoming, or just not supported with UIXComponentBase?
I seems like it could be a very big source of problems if IDs change
between requests, as decodes will have a lot of problems. Should
UIXComponentBase be calling setId after generating an ID in the
getClientId function?
This was found on 1.0.3-SNAPSHOT
Any ideas?
Thanks,
Andrew
