In order to make it, I had to set bindings in the backing bean (UIComponent instances) for the three controls. Additionally had to flag each of the amount controls (inputtext) by embedding in their valuechangelisteners method bodies a flag condition, in order to ommit their execution when the change was originally performed in another control (had to do it this way since removing and restoring valuechangelisteners didn't work). When a valuechangelistener is "truely" flagged and its body is executed, I set manually through bindings in the backing bean the values for the affected controls and the backingbean value properties.
Does it have to be so complicated? In fact I guess so, then otherwhise the lifecycle is constantly overriding the changes back to their original values. Even removing and restoring the value change listeners before and after setting the component value, makes no effect, since I guess the update in the property is scheduled in an upcoming lifecycle phase instead performing the change immedately (UPDATE_MODEL_VALUES phase right?).
Handling the whole differently would require scheduling changes in the PhaseListener, which would make it even more complicated.
I believe my approach is correct, however it would be great if anyone could confirm it.
I apologise for the length of this post, and thanks for taking the time to understand the issue.
You should be able to set a bean internal property referenced only by the ValueChangedListeners. Each listener would set that property with a unique value, just like a radio button would do. Meaning that the internal property can be an enum, if you want.
When an action is fired, the EJB lifecycle is run. Since valuechangelisteners fire ONLY if the value changes, the enum will be set based on which value was modified on the client. In cases where more that one item was modified, you have an ambiguity and it's up to you to figure out how to resolve it. Such is life.
The action processor can then incorporate a switch statement, with the branches of the switch based on which item was modified. They would then update the unmodified object's backing properties accordingly so that when the page redisplayed, the display would reflect the cascaded action as part of its normal property fetching process.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 21, 2010
Hmm... interesting point of view. I will give it a shot and let's see. Indeed my approach works fine but for complex forms (basically more interrelated components) maintainance would become hell. Must figure out something lighter to handle.