Raphael Mankin wrote:
If there were many such IF statements in my templates I would tend to use separate templates for the user states (or whatever) and let the controller route to the appropriate one.
Sure, but this could be the site/login template, included from the site/sidebar which got pulled in by the site/layout template, and so on. It's probably just one of many different template fragments that render parts of the UI chrome and have little or nothing to do with the application-specific functionality of any particular URL/page/handler. For my controller to make these decisions would require it to know a lot more detail about how I've structured my templates than I would be comfortable with. That's not to say that there aren't times when it's the right thing for the controller to influence the presentation, as long as it can do so relatively cleanly. For example, an application controller might change the INCLUDE_PATH of a template engine to add one or more template directories, so that the user/status template gets magically selected from the right directory, either templates/user/logged_in or templates/user/admin, for example. However, that does tend to cement the presentation architecture and application server quite tightly together. Of course, that may be *exactly* what you need for a particular application (delivering mobile content via handset-specific view objects comes to mind as a recent example of this), but that doesn't mean it's always the best approach. I totally agree that the application controller should decide about selecting the right template based on the task that it has just performed (e.g. displaying the login/failed.html or login/success.html template), but in this case we're talking about the various presentation aspects that aren't necessarily the responsibility of any particular controller or single part of the application. A