The pattern used in most PHP frameworks (Cake, CI, ZF) is not plain MVC - it is Front Controller (and friends): you work with requests, you route them, you dispatch them to actions, actions read request parameters, talk to model, pass data to the view, view gets rendered to response and uses some kind of helpers to render fragments that get reused, response gets serialized, finished. A form in a typical MVC PHP app might lead to a different action than the one that rendered it. Controller calls view and has a chance to act before the view is rendered. Routing is important, because actions are tied to urls.
In JSF there is no such thing. Routing and redirecting (at least the one that happens before processing the view) are not part of JSF, they are one level of abstraction below JSF. You can add routing and redirects using some other libraries or custom code, it's rather easy. The mechanism in faces-config.xml is not really routing and yes, you are right, it is particall only with wizard-like scenarius. You do not use it to structure your web application (if only because it only applies to POST requests).
Actions in JSF are not chosen by a centralized router/dispatcher but by components. In most cases you do not even need an action, because view and model suffice. You might imagine that JSF treats each component of a page as a little MVC stack of its own. The component itself (eg. a text input, a dropdown) is responsible for retreiving data from request, converting and validating the data, rendering HTML, and passing the data to controllers (and other components) by putting them in the right place in the model.
Thanks to this, things that require an action controller in, say, Zend Framework, like paginating data, searching, editing multipage forms with custom view logic etc. usually do not require more than view and model in JSF (possibly validators or converters). Components invoke actions only when persisting data to database or when data processing becomes more complex. Even then the actions get triggered after the view has read all the data from request, so dispatching an action is not in any way connected with routing. Each commandlink or commandbutton must come back to the precise page that rendered the original form, because only the components on this page are able to understand the request and update the model. Because routing has nothing to do with firing actions, it is left out of the framework (you can do pretty urls and nice routing using libraries like PrettyFaces, but it's not part of JSF).
JSF redirects are executed as results of actions (based on a string returned by actions), so while it is possible to execute a redirect and some logic before it, the template must be processed before the redirect.
In PHP it is common to think of reading data from database as "an action to do before I display the view". In JSF it is not an action, but a part of initializing your model; as such it belongs in a method inside your model managed bean - such method should be annotated with @PostConstruct and it will be executed by the JSF DI container before you get the reference to the bean and after all the dependencies had been injected.
If you really think you need to fire some action before page displays, use event listeners - but be warned: probably you are doing something wrong.
The hidden assumption behind Cake/Zend framework is "there is one main thing to do on each HTML page and the display concerns mainly this one thing". The hidden assumption behind JSF is "as far as we can tell, the whole application is just this one page full of stateful controls"
If you did not invest too much time in JSF already, you may first try to switch to JSR-311. It is a new alternative presentation layer for Java EE, that is focused on restful approach: restful urls, routing, resources etc. It has pluggable templating and its RI has a beautiful MVC layer. If you like Zend Framework, you will love it. You can use JSR-311 to practice EJBs, JPA and other Java EE stuff, and then come back to JSF when you are already experienced with Dependency Injection, transaction management and so on, and can focus on stateful web presentation. An example code in Jersey (a jsr-311 RI, you have it bundled with your glassfish/netbeans) might look like this:
@EJB
UsersDao usersDao;
@Path("/users/detail/{userId}")
public void userDetail(@PathParam("userId") int userId){
return new Viewable("users/template.jsp", usersDao.getById(userId));
}
Warning: jsr-311 is service-centric (json, xml) not web-application-centric, and the templating engine is pluggable, so there are no jsr-311 view helpers (when reconstructing urls you are pretty much on your own).
