Zero or one application-defined "Actions" may be invoked by RSF as the last stage of POST (state-altering) request handling. The action to be invoked is defined using a method binding EL, and references the target method by bean path - the action code is below the bean line and requires no framework interface to be implemented by the client code.
A component which signals an action is to be invoked when the corresponding UI control is operated is of class UICommand, which holds the relevant method binding. After the action is invoked, successfully or otherwise, control passes to an (again implementation-defined) ActionResultInterpreter, which, above the bean line interprets the action's result and computes the view to be rendered on the next cycle, after the client redirect.
It's imagined that as RSF matures, for some class of applications the Action may actually end up being empty. Since many typical "actions" simply update some persistent state based on the request and process errors and validations in a fairly typical way, the "real work" of the action could all be performed by the AlterationWrapper, DARApplier and the ActionResultInterpreter. In some ways this represents a loss since it appears that we have traded code below the bean line for code above - but AIW code is highly economical and may be entered only once per application/ORM technology, and ARI code may not be code at all, but entered in some form of web flow technology. In this way RSF does indeed aim for a "codeless" application, but unlike other "hard-coded" codeless frameworks (Cocoon e.g.) one in which code could very easily enter where needed.
See also tips when an action handler fails.
You can post comments and questions on this page using the following blog. Please set your name using UserPreferences before posting.