Zend Controller & Zend View

I've seen two articles describing how to integrate Smarty with Zend_View, Integrating Smarty with the Zend Framework at Zend Developer Zone and Zend Framework: Using Smarty as template engine at Dmytro Shteflyuk's blog. Both of these are very outdated by now.
So here's take three on integrating Smarty with Zend_View, this time hopefully staying useful for a longer time since the Zend Framework has reached version 1 now.

Yet another demonstration of the power of the Zend Framework. This works with ZF Version 0.8 as well as the recent release of 0.9.(x?)
This time we’re going to create dynamic breadcrumbs that might look like this:
Home / Article / Editing: My Post Title
Utilizing view helpers, all we need to do is do a little prep work; in my case, I use a bootstrap controller that all my controllers extend.

It's been a long, and hopefully interesting, road to Part 7. In this concluding entry to the long running, and oft delayed, "Complex Views with the Zend Framework" series I introduce the Zend_View Enhanced Proposal for the Zend Framework, elaborate on its operation, and provide some opinions on the ongoing debate over its implementation. So sit back, relax, here's another long (be patient ;-)) blog entry.

One could tweak Zend Framework's Router_Route to meet almost all your routing needs. But what if you want something beyond what that package can offer? You can make your routing dreams come true with making your own custom router, all you need to do is implement Zend_Controller_Router_Route_Interface (that's a mouth full).

It's 4:30 AM, and I'm sitting in an airport lounge waiting for a flight to Brussels after accidentally bumping into Zeev and a couple of other guys (Amnon and Matti) from Zend, on their way to a management meeting in the US. Since they had to board, and I'm left all alone and still have an hour or so to pass, I'm going to share a nifty little thing I found in Zend Framework a couple of days ago: A nice and clean way to generate relative links in view scripts.

Contrary to what my tutorial says, I'm one of those people that doesn't want to have to render my common header and footer templates in every single view script file. I prefer a standard site-wide layout script file that will display the content of the action script files within it.

The Zend_Controller_Action_Helper_ViewRenderer action helper is a great bit of code that automates rendering a view template based on which action has been called. This is very useful, but renders the action template, not my layout template. To solve this, I am experimenting with extending the Zend_Controller_Action_Helper_ViewRenderer and overriding it so that it know about my layout template. I also prefer to use the view suffix "tpl.php" for my view scripts, so I've made my class automatically set my preferred view suffix.

Over the last week a lot of the activity on the Zend Framework mailing lists has revolved around the introduction in 1.0.0 RC1 of the ViewRenderer action helper. As of RC1 this helper has been enabled by default. Lot's of queries have been raised about how to disable, modify it, and generally how current applications can be made to work with the ViewRenderer.

In parts 1, 2 and 3 I've been taking a look at the Zend Framework and putting together a broad picture of a potential implementation to add support for complex multi-part web pages. This refers to the practice of building a web page in an application from a number of common reusable elements. An example of such elements include header sections, footers, menu bars, widgets, etc, which surround the main content returned by any client request. In Parts 2 and 3, I introduced two useful design patterns for this purpose: Composite View and View Helper.

In the previous two parts of this series of blog posts, I've been looking at the task of implementing complex views with the Zend Framework. Part 1 looked at what complex views are, what support for complex views the Zend Framework offers out of the box, and a reference to two design patterns useful in adding further support: View Helper and Composite View. In Part 2, I tackled the View Helper design pattern.

It's been a while since I continued this series. Unfortunately real life workloads are unforgiving of the best of intentions ;-). Part 5 of our series takes a small time-out from approaching a Composite View solution to reusable Views to take a peek at a simpler approach useful for simpler types of web applications. As we've discussed previously Composite Views allow the nesting of reusable View elements, effectively building a View based on a hierarchy of Views. But often there are simpler solutions to simpler problems. One such solution is the Two-Step View pattern, sometimes called Layouts if implemented in a specific way (as we do below!).