Let's take a concrete example of the feature. We would have a new <b:reaction> component (the name is temporary). Its one and only goal is to react to some events and do something in consequence. Let's call on (or event) the attribute in which we will provide the events to listen and operation (name inspired from <rich:componentControl>) the attribute which will contains the function to call.
Hey wait, no target? Nope. It's up to the one who trigger the event to also specify the target. For example:
What does that mean? When the a4j:ajax will be activated, it will have to render input1 component. Just before doing that, it will trigger (for example, not sure if it does that yet or not) an event (let's call it "beforeRender"). Since b:reaction is listenning for that event, it will also be activated right after that.
And when activated, it will call the function "addStyleClass('disable')" (which would, in this example, add the "disable" CSS class to the component). Last question: which components will receive the call? All the ones specify inside the reaction attribute of the a4j:ajax.
So here, @render is a new reserved word to indicate all components which will be render by a4j:ajax. We could also have put @form or @all or a list of id like "input1 output2".
Let's move forward! A reaction should be able to listen several events:
To do several operations:
To have some nice methods to do easy operations out-of-the box:
As I said at the beginning, by default, <b:reaction> would be bind to the body. But sometime, it would be usefull to narrow it only to a particular section of the JSF tree. So in fact, it should be bind to its parent (which can be the body, or a form, or a panel, or anything...).
We can also add an attachTo attribute. If present, the reaction would only react if the event comes from one of the components specify in this attribute (and also inside its scope of course).
Let's finish with the question: "Why such a component? What are the use-cases?". The idea was from Bernard in order to block some components in the client-side during an ajax request so the user cannot interact with them before the end of the request. I think it's a valid concern (100% with you Bernard!) and having such a component to play with JSF component on the client-side would be really nice IMO.
It's true that there is already some ways to achieve that. But having a generic way to do so would be awesome.