Well actually, I normally do this in JavaScript. However, I think you have the right approach, just maybe a little overcomplicated.
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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.