With the introduction of the ViewRenderer component into the Zend Framework has come all sorts of troubles for all sorts of developers. Thankfully, there's posts like this one from Pádraic Brady that helps out with some of the more common issues people are seeing (a problem/solution approach).

The ViewRenderer "action helper" is the class Zend_Controller_Action_Helper_ViewRenderer. It's primary purpose is to facilitate the automated rendering of View scripts (templates) based on the generally accepted Zend Framework conventions. It's these conventions which will cause a lot of people grief, since the previous reliance on programmers defining the template to render has likely led to inconsistent template names.

Included in the post is a list of some of the common issues developers have including "ViewRenderer is enabled by default", "Inconsistent location of template files" and "Reusing template files across Controller actions". For each, he's included a "quick hit" solution to get you back on the straight and narrow road to having a nicely working Zend Framework application.

With the introduction of the ViewRenderer component into the Zend Framework has come all sorts of troubles for all sorts of developers. Thankfully, there's posts like this one from Pádraic Brady that helps out with some of the more common issues people are seeing (a problem/solution approach).

The ViewRenderer "action helper" is the class Zend_Controller_Action_Helper_ViewRenderer. It's primary purpose is to facilitate the automated rendering of View scripts (templates) based on the generally accepted Zend Framework conventions. It's these conventions which will cause a lot of people grief, since the previous reliance on programmers defining the template to render has likely led to inconsistent template names.

Included in the post is a list of some of the common issues developers have including "ViewRenderer is enabled by default", "Inconsistent location of template files" and "Reusing template files across Controller actions". For each, he's included a "quick hit" solution to get you back on the straight and narrow road to having a nicely working Zend Framework application.

Rob Allen has two new posts today, both revolving around the same thing - an update to the Zend Framework called the action helper ViewRenderer. The first just mentions an update to his "Intro to the Zend Framework" tutorial PDF, but the other gets a little more in-depth:

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.

He illustrates with some code, an example that shows how to tell the ViewRenderer about his "tpl.php" files and link them back to the action that's called on the URL.

Rob Allen has two new posts today, both revolving around the same thing - an update to the Zend Framework called the action helper ViewRenderer. The first just mentions an update to his "Intro to the Zend Framework" tutorial PDF, but the other gets a little more in-depth:

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.

He illustrates with some code, an example that shows how to tell the ViewRenderer about his "tpl.php" files and link them back to the action that's called on the URL.

On the Zend Developer Zone, Matthew Weir O'Phinney has posted an announcement about the latest development on the Zend Framework front - the ViewRenderer module.

Yesterday, I committed a change to core in preparation for the 1.0.0RC1 release that, while breaking backwards compatibility slightly, will also greatly simplify the integration between the controller and view components.

One developer, Ralph Schindler, felt it didn't go far enough, and posted an issue in the framework issue tracker detailing an idea he had for adding more integrated View dependency injection to Zend_Controller_Action. After some thought and discussion with him, I countered with a new action helper, the ViewRenderer.

This new bit of functionality allows you to get rid of those pesky view objects in Controllers, set default rendering options for the controllers, let you autorender view scripts based on the current action and much more.

Check out the post for some example code.

On the Zend Developer Zone, Matthew Weir O'Phinney has posted an announcement about the latest development on the Zend Framework front - the ViewRenderer module.

Yesterday, I committed a change to core in preparation for the 1.0.0RC1 release that, while breaking backwards compatibility slightly, will also greatly simplify the integration between the controller and view components.

One developer, Ralph Schindler, felt it didn't go far enough, and posted an issue in the framework issue tracker detailing an idea he had for adding more integrated View dependency injection to Zend_Controller_Action. After some thought and discussion with him, I countered with a new action helper, the ViewRenderer.

This new bit of functionality allows you to get rid of those pesky view objects in Controllers, set default rendering options for the controllers, let you autorender view scripts based on the current action and much more.

Check out the post for some example code.