Padraic Brady has posted part seven of his series on building a blogging application with the Zend Framework as a base. This time he's working on the output of the entries - using Zend_View to standardize the look and feel.

In previous parts we've been using View Helpers without even noticing it. Zend_Form doesn't generate forms by itself, rather it delegates most of the HTML generation to a set of View Helpers like Zend_View_Helper_Form. The problem with such output, is that View Helpers can only generate XHTML 1.0 Strict output if we actually inform them of the standard to use. [...] What we should do, is make the Doctype of our View more dynamic. This is achievable by using the Doctype View Helper.

Padraic talks about the different parts of the View layer in the framework (helpers, partials, placeholders) that were mentioned in previous parts. He shows how to change up his current setup to work with the Doctype View Helper to change the view and make it UTF-8 compliant.

He shows the changes to the bootstrap file, how he's grabbing the entries from the database and how he pushes that out to the view to be displayed. He also creates a custom view helper to create the entry URLs for each of the posts (Wordpress users out there, these are the stubs).

The Zend Developer Zone has posted a new tutorial (from Matthew Weier O'Phinney) about a handy feature of the Zend Framework's view layer - view helpers that can be added in and reused across an application to do some pretty cool stuff.

A View Helper is simply a class that follows particular naming conventions, When attached to a view object, you can call the helper as if it were a method of the view object itself. The View object retains helper instances, which means that they retain states between calls.

View helpers can be use to do things like manipulate view data for more complex operations and carrying over data between two views, limiting the number of fetches that have to be done. He shows how to create a simple helper - My_Helper_FooBar - that just appends "fooBar " to whatever's passed in. He also talks about some of the default view helpers (like form fields), partials, the doctype() helper, capturing/caching content to be used later and the use of placeholders.

On his blog today, Matthew Weir O'Phinney offers some helpful advice about using the placeholder functions of the Zend_View component (like headScript or headLink) to make coding in the Zend Framework that much easier:

Somebody asked for some examples of how I use the headLink(), headScript(), and other placeholder helpers, so I thought I'd take a crack at that today.

He looks at the different categories of placeholders and illustrates with examples of each: Doctype Hinting, Content Aggregation, Capturing Content and finally, putting them all together into a custom layout that uses docType, headLink, headStyle and headScript.

Pádraic Brady continues his series on working with Complex Views in the Zend Framework with this new article - part seven focusing on the Zend_View Enhanced method.

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.

In this final entry of the series, he recaps previous concepts (like Partials/Layouts/Controllers/Placeholders) and how far reaching the Zend_View Enhanced component is. He also includes some of the helpers and interfaces he's proposed for the module including:

• Zend_View_Helper_Partial
• Zend_View_Helper_Controller
• Zend_View_Helper_HeadScript
• Zend_View_Helper_Doctype
• Zend_View_Helper_HeadStyle

He takes each of the concepts mentioned above and applies these different helpers/interfaces inside them, illustrating with some sample code as needed.

Pádraic Brady continues his series on working with Complex Views in the Zend Framework with this new article - part seven focusing on the Zend_View Enhanced method.

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.

In this final entry of the series, he recaps previous concepts (like Partials/Layouts/Controllers/Placeholders) and how far reaching the Zend_View Enhanced component is. He also includes some of the helpers and interfaces he's proposed for the module including:

• Zend_View_Helper_Partial
• Zend_View_Helper_Controller
• Zend_View_Helper_HeadScript
• Zend_View_Helper_Doctype
• Zend_View_Helper_HeadStyle

He takes each of the concepts mentioned above and applies these different helpers/interfaces inside them, illustrating with some sample code as needed.

http://www.phpdeveloper.org/form/view/type/addnews PHPDeveloper.org: PHP News, Views, and Community In a new post Paul Jones points out some of the new behaviors that the extension is showing in the latest of the PHP 5 seres (version 5.2).

He starts with a code example that would work with a previous version of PHP/PDO that would allow for the binding of a single value to multiple places in the SQL statement. But:

Sadly, this is no longer the case in PHP 5.2.1. For valid reasons of security and stability in memory handling, as noted to me by Wez Furlong, the above behavior is no longer supported. That is, you cannot bind a single parameter or value to multiple identical placeholders in a statement. If you try it, PDO will throw an exception or raise an error, and will not execute the query. In short, you now need to match exactly the number of bound parameters or values with the number of placeholders.

Unfortunately, this is used quite often in Paul's Solar framework, so an update to the Solar_Sql_Adapter::query() method has had to been made to allow for the binding of multiple items automatically. It works by incrementing the bind location (like ":foo") with numbers at the end - simple and effective - and you can still pass an array to it and have it automagically work.

http://www.phpdeveloper.org/form/view/type/addnews PHPDeveloper.org: PHP News, Views, and Community In a new post Paul Jones points out some of the new behaviors that the extension is showing in the latest of the PHP 5 seres (version 5.2).

He starts with a code example that would work with a previous version of PHP/PDO that would allow for the binding of a single value to multiple places in the SQL statement. But:

Sadly, this is no longer the case in PHP 5.2.1. For valid reasons of security and stability in memory handling, as noted to me by Wez Furlong, the above behavior is no longer supported. That is, you cannot bind a single parameter or value to multiple identical placeholders in a statement. If you try it, PDO will throw an exception or raise an error, and will not execute the query. In short, you now need to match exactly the number of bound parameters or values with the number of placeholders.

Unfortunately, this is used quite often in Paul's Solar framework, so an update to the Solar_Sql_Adapter::query() method has had to been made to allow for the binding of multiple items automatically. It works by incrementing the bind location (like ":foo") with numbers at the end - simple and effective - and you can still pass an array to it and have it automagically work.