CMS Pages

The default ZF MVC structure makes a lot of sense for web applications. It only stands to reason that CRUD functions, for example, should be encapsulated in a single controller class.

On the other hand, it is difficult to explain to new developers why you need to create the controller class, a new view folder, and a view script to render a simple content page.

I think it is time to start looking at these as separate components of a CMS site. Well designed CMS sites generally consist of a number of landing pages, which load dynamic content from modules, such as news, events, or blog posts. This abstraction makes it possible to aggregate content, making the most out of your resources.

I am working on a different way to manage these pages. From a high level it works like this:

1. You build a site much like you would a static HTML site, but you build it out of Zend View scripts.
2. The CMS indexes the site folder and adds each page to the router. The CMS routes to the pages in exactly the same way that a standard site would; /about/team would render /site/about/team/index.phtml.

Each of these view scripts can have an optional controller, which is a little different than a standard Zend Controller. There is a one to one relationship between controllers and view scripts. If you render /about/team.phtml the CMS will look for a controller class in /about/TeamController.php. Since these controllers are tightly coupled with the views they are able to share information much more easily. You can access any public property in the controller from the view, without explicitly passing it.

A few Notes

• This works in addition to ZF; the rest of your application functions exactly like any other ZF application. You can still create as many controllers and modules as you need, and you should. This is where all of the data management happens.
• These views are rendered through the standard Digitalus Framework template engine.