In this new post to his blog Nikita Popov looks at an update that might have gotten lost in the shuffle of new features coming in PHP 5.4 - some updates to htmlspecialchars.

One set of changes that I think is particularly important was largely overlooked: For PHP 5.4 cataphract (Artefacto on StackOverflow) heroically rewrote large parts of htmlspecialchars thus fixing various quirks and adding some really nice new features. Here a quick summary of the most important changes: UTF-8 as the default charset, improved error handling (ENT_SUBSTITUTE) and Doctype handling (ENT_HTML401,...).

He goes into each of these three main features in a bit more detail, providing code to illustrate the improved error handling and the new flags for Doctype handling (covering HTML 4.01, HTML 5, XML 1 and XHTML).

On the SmartyCode.com site, there was a new article posted recently looking at making the output of your Zend Framework application XHTML compliant.

Serving XHTML is often misunderstood by php developers. Frontend engineers simply include the XHTML doctype to their documents, without actually serving document as XHTML. This triggers majority of the browsers to treat such pages as 'tag-soup'. [...] This front controller plugin's code mostly takes concepts from the excellent article by Keystone Websites, but implements in Zend Framework environment in an object-oriented way.

The code works as a plugin to the controller and runs a few checks on the contents of the data being pushed out (dispatchLoopShutdown) and returns the correct header information (DOCTYPE, language attribute) in the correct XHTML format for the data. When the plugin is registered, all it takes is a call to the "doctype()" method to output the correct information.

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.

Builder.com as posted a quick tutorial on working with the DOM functionality in PHP to create a dynamic XML document (Doctype and all).

Over the course of this article, I'll be introducing you to the main functions in this API, showing you how to programmatically generate a complete well-formed XML document from scratch and save it to disk.

They start off with creating the Doctype declaration before actually adding the content into the file (elements and text nodes), adding some attributes to the nodes, putting CDATA blocks inside them, and pushing out the results on the other side to be saved to a local "order.xml" file.

You can also download this article if you'd like to work with it (and its included PHP files) on your own.

Builder.com as posted a quick tutorial on working with the DOM functionality in PHP to create a dynamic XML document (Doctype and all).

Over the course of this article, I'll be introducing you to the main functions in this API, showing you how to programmatically generate a complete well-formed XML document from scratch and save it to disk.

They start off with creating the Doctype declaration before actually adding the content into the file (elements and text nodes), adding some attributes to the nodes, putting CDATA blocks inside them, and pushing out the results on the other side to be saved to a local "order.xml" file.

You can also download this article if you'd like to work with it (and its included PHP files) on your own.