The idea of avoiding the use of client ids in the generator for state saving has now been abandoned in favor for a simpler solution.
Initially, an alternative approach was implemented where, instead of client ids, a generic numeric id was used. While, this temporarily solved the problem that originated this issue (ICE-7302), it could cause problems when a component is repeated inside a UIData container or ui:repeat. Therefore, this change was reverted and a simpler solution was implemented to avoid using client ids when setting properties of programmatically-generated components, in general, not just menus.
The approach consists in checking if the component is attached to the component tree or if it is disconnected. If it is disconnected, then no client ids will be used as keys for state saving, and instead, the same approach used when setting a property during the Render Response or Restore View phases is applied, which consists in setting the default values of the component. There is no intrinsic differentiation among instances of the same component in this scenario, but since the components are already created programmatically in the bean on a per-instance basis, then there's no need to handle different instances in the setter methods in this case.
Improvement
Major
DEL
/icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/component/StateSavingIdGenerator.java
The idea of avoiding the use of client ids in the generator for state saving has now been abandoned in favor for a simpler solution.
Initially, an alternative approach was implemented where, instead of client ids, a generic numeric id was used. While, this temporarily solved the problem that originated this issue (
ICE-7302), it could cause problems when a component is repeated inside a UIData container or ui:repeat. Therefore, this change was reverted and a simpler solution was implemented to avoid using client ids when setting properties of programmatically-generated components, in general, not just menus.The approach consists in checking if the component is attached to the component tree or if it is disconnected. If it is disconnected, then no client ids will be used as keys for state saving, and instead, the same approach used when setting a property during the Render Response or Restore View phases is applied, which consists in setting the default values of the component. There is no intrinsic differentiation among instances of the same component in this scenario, but since the components are already created programmatically in the bean on a per-instance basis, then there's no need to handle different instances in the setter methods in this case.