1

Should I expect that the results of UIComponent#getClientId() could change across a user session? I'd like to save the full clientId reference to a UIComponent and use it later.

When user adds a dynamic component:

myBean.setClientId(composite.getClientId());

Much later in the session when the user "Saves":

String clientId = myBean.getClientId();
UIComponent composite = view.findComponent(clientId);
  • Maybe different JSF implementations don't guarantee the same clientId across the session?
  • Maybe dynamically adding and removing UIComponents (or whim) will cause one of the containers in the path to change an index across requests?

I saw this great Q&A and I'm not sure if it fully answers the question of saving a clientId and using it several requests later in a session or in a dynamic form: when-and-how-is-clientid-generated-in-jsf

Thanks

Community
  • 1
  • 1
AAron
  • 428
  • 3
  • 11

1 Answers1

0

If the client ID contains an autogenerated ID because the developer didn't specify a fixed component ID via the id attribute, then there's no guarantee that it will be the same in another request. Certainly not if the component tree is programmatically manipulated by component libraries or even yourself by adding/removing components without a fixed ID. The autogenerated ID on the "same" component may then change depending on the component's position in the total tree.

This is not JSF implementation specific. The JSF specification only guarantees that the (generated) client ID is the same across the entire request. See also the javadoc:

The return from this method must be the same value throughout the lifetime of the instance, unless the id property of the component is changed, or the component is placed in a NamingContainer whose client ID changes (for example, UIData). However, even in these cases, consecutive calls to this method must always return the same value.

UI component instances are request scoped. So, the #{myBean} in your example should absolutely not be in a broader scope than the request scope in order to guarantee that the client ID can be reused to find exactly the desired component. If the #{myBean} is in a broader scope, then this would technically only work if the client ID is composed of solely fixed IDs.

Nonetheless, manipulating the component tree via Java is a bad idea. Use JSTL instead. See also a.o. How does the 'binding' attribute work in JSF? When and how should it be used?

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I'm currently using a clientId path that has no `j_idt#` Ids, but now I think I'll avoid the issue by making my core componentIds unique and find them with `root.visitTree()` (ex: ``). – AAron Sep 23 '15 at 16:37
  • Thanks for advice and tips on Java-modifying component tree. Always looking for alternative approaches, but I've currently gotten a clean/solid approach that satisfies my requirements. Will look at JSTL to try to understand the design you are suggesting. – AAron Sep 23 '15 at 16:44