JSF apps have little or no user-written Controller code in them. Mostly it uses canned Controller components (the FacesServlet and JSF Tag processors) which are wired up in the Views to their corresponding Models.
Action processors are not Controllers. They're the entry into the business methods that are fired when a command Controller such as a commandButton or commandLink is activated. Or lately, by AJAX, but the same mechanism applies. "Pure" MVC doesn't actually address what to do with data, just how to keep a model and its view in sync via Controllers. In the real world, of course, we do have to jump off into practical applications (business logic), and that's what the Action methods for.
Ideally, one would keep the Actions separate from the Backing properties, but in actual practice, it's usually more trouble than it's worth.
It is not a good idea to attempt to invoke Action methods as though they were general-purpose functions. Although JSF2 makes parameterizing things easier, the original concept was for Action methods to accept no parameters and return a navigation indicator (
String). Parameters are neither required nor desirable, because the action processor should be accessing data directly from the Model, not from the View. Putting stuff like that in the View clutters up the View definition, ties it more tightly to a specific usage, adds network overhead, and on top of all that, is a potential security hazard.
Just to make things even more problematic, the EL language used on View definitions is NOT java, any more than JavaScript is. EL has its own syntax, restrictions and modes of operation. When it comes to EL, simpler is better.
