I recently received an email asking for my advice about how to handle a form that appears on every page. I want to add a newsletter sign up box to layout.phtml so it will appear on every page. The layout->content() comes from several different action controllers... So how do I handle the newsletter sign up? I thought that the answer is long-winded enough to be worth writing a blog post about. One way to do this is to use a action helper, so let's build a simple application to show this solution.

He walks you through the creation of the simplest part first - the form that will live inside of the view helper. He chose a signup type of form with a username, email and submit button. He helps you create an action helper and the view helpers to help inject the form into the layout of each page. Then, with a simple call to "$this->signupForm()" you can drop it in anywhere in the layout.

For me one of the best features of Varnish is ESI (Edge Side Includes). It allows you to combine elements with different lifetimes into a single page. This way you don't need to regenerate a complete page as soon as a news listing somewhere on the page changes. And you can still cache pages while displaying user-specific information somewhere on the page. This lowers the load on your application even further and it can also help in simplifying your application, by focussing purely on the content of the page and loading all other elements via ESI.

He talks about the upsides and downsides to using the technique and what to avoid when implementing it in your Varnish config. One solution to the problem is sending an ESI "marker" to tell Varnish that a certain bit of content needs to be updated. He shows how to put it to use with a Zend Framework view helper that adds a special "esi" tag to the page when the content for a URL needs to be updated.

This is certainly wonderful and exciting, but the reality is that for the most part, Zend_Navigation is a pretty useless component of Zend Framework until you have a way to get the data out of the structure you've built. And since navigation is a component of most people's views, we have a view helper to give us the tools we need.

This view helper, "navigation", gives you some interesting functionality including what he illustrates - fineOneBy, htmlify, building breadcrumbs, menu generation and a way to finally render the menu as output. You can see more of the options/methods in the Zend Framework manual for the helper.

This post is the second part of my introductory text on Zend Framework, Starting with Zend Framework. This time I cover the basics about controllers, actions, view scripts and view helpers. On request routing and the Front Controller I will write one (or more) big post(s), so this part won't be explained now. I will also skip explaining the models; they deserve their own post.

He goes a step further and looks at Controllers - what they are and some intro steps to you making one of your own - and the parts around them, the views, actions and view helpers.

When I first began working with Zend_View on a project at work, I noticed that the Url view helper was a bit of a pain to use. It was rare that I didn't want to specify one or more of the action, controller, and module in my call along with the other Route assembly parameters.

He wanted to be able to get around some limitations of the helper - use arrays to help label the calls more readable and to be able to refer to other actions in the same controller. He actually made another view helper, one that extends Zend_View_Helper_Url with a few optional parameters including the extra data he wanted in an array. You can see the code at the bottom of his post (he credits Andy Best with development on the idea too).

In the second of my Addendum posts which revise previous entries either for missing functionality, progressive changes and enhancements, or reader comments, I revise the design and styling of the blog application. There's not a lot to discuss in this entry since the majority of changes are to the HTML and CSS of the blog.

He includes the phtml template files for the updates to the blog's layout along with the code for the new view helper (and tips on making them global and optimizing them).

With the inclusion of Zend_View Enhanced as first documented, discussed and publicized in this blog series, in the Zend Framework as of 1.5.0 I'd like to thank everyone involved in the process. [...] The main problem of a complex View, is that the current Controller is only aware of a subset of its own required Model (data) and the current View. So how do do you get the View to include extra sections - for example, details from Technorati for your blog - which are common to ALL pages?

Normally, a call to _forward() would have been the norm, but this was more often overly complex for what the developer wanted to do. The new Composite View and View Helpers seem to be the remedy. They make it simpler to grab that information and pull it in without the need to make a whole other framework request to do so.