In my previous post in this series we looked at how Zend Framework applications can be bootstrapped. We saw the configuration file (
application/configs/application.ini) and the
Bootstrap class (in
application/Bootstrap.php) from a demo blogging application, Postr. What happens once your application is bootstrapped and run? That’s where Zend Framework’s routing and Model-View-Controller (MVC) components come in (technically there are a few steps in-between, but we’ll come back to that in a future post).
- Your domain objects. There is no
Zend_Modelsince your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).
- See example Models in
- The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of
.phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).
- See example Views in
- Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.
- See example Controllers in
By default, Zend Framework will route requests based on URI segments as follows:
A few example URIs:
foo/bar(foo controller, bar action)
foo/bar/baz/shaz(foo controller, bar action, baz=shaz)
It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.