Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

In the second part of their look at using closures in PHP as view helpers, DevShed improves upon their original code by adding some additional classes and using them in the closures.

The best way to show you how using anonymous functions can help you to develop more efficient OO applications is with some functional, hands-on examples. With this idea in mind, in the installment that preceded this one, I implemented an extendable template system. This system could spawn view objects and render the template files associated with these objects.

In this second part of the (two-part) series they include "Serializer" and "FileHandler" classes and show how to use them inside of the closures to lazy-load in data from an external file and work with it as serialized content.

New on DevShed today there's a tutorial looking at using one of the newer features of PHP, closures, as view helpers in a basic templating system.

In this two-part tutorial I'll be showing you, in a step-by-step fashion, how to use the goodies offered by closures in the implementation of an object-based, easily extendable template system. This system will allow you to embed anonymous functions easily into template files, and call them as typical view helpers, too.

He starts the process of creating the templating system by defining two interfaces, the View and DataHandler. Using these as a base, he creates an instance of the ViewInterface (a "View" class) that can set the template file to use, set values to be displayed and render the formatted output. Included is a basic template and how to use the View class to set values into it. The "render" method is called on the view and the HTML markup is produced. The closure comes in when they try to call a value "clientIp" that needs to do something more complicated than just having a string assigned to it.

Lorna Mitchell has a new post today spotlighting a handy feature of the phpMyAdmin tool - the visual designer view. It allows you to build (and see) the relationships between your MySQL-based application's elements.

I'm happier at the command line, but needed some graphical representation of information and easy ways to export example queries for the book I'm working on. I noticed that phpMyAdmin now has a Designer tab, which shows relationships between tables and allows you to define them.

She includes two screenshots of the process of setting up a foreign key on two tables. You can find lots more articles related to the designer view here.

On DevShed today there's a new tutorial posted talking about the Liskov Substitution Principle (part of the SOLID set of principles) and how to use it in a practical example using some object-oriented PHP.

However, not all is bad with Inheritance. When used properly it can be a great ally. The question that comes to mind is: how can you keep away from building derivatives that behave totally different from the chosen abstraction(s)? Here's exactly where the Liskov Substitution Principle (LSP) comes into play.

They choose to illustrate the principle in the form of a view renderer that, when an unintentional issue happens, throws a new exception. He creates the abstract class to generate the view objects and creates a few child objects that extend it. using these, he creates a set of templates that render a header/footer/body with the data given. The problem comes up when he tries to work with his objects and a partial view instead of a composite view is passed in.

It's a complicated situation to follow, but it does help make the principle a bit more clear. I'd suggest following it all the way through and possibly even trying out their code (included) to make it even more clear.

Anna Filina has a new post showing how you can integrate a documentation format that's become a bit more popular recently (due partially to its increased use on github), Markdown, into a Symfony application.

I needed to create a number of static help pages in three languages in a Symfony 1.4 application. Using the XLIFF translation files seemed absurd, since I knew that I will include a lot of HTML. [...] And so, I decided to create partials using the following structure: _docs/{lang}/{title}.php. This method would organize my pages nicely and will only load what is needed. Then, I remembered that we were planning to hire a technical writer for the rest of the manual. I wanted to make his life as easy as possible and the source files easy to read for everyone.

She found the solution in Markdown and has included a step-by-step guide to getting it integrated with Symfony using this parser. It's loaded as a helper and used to parse the partial view's content. You can find a quick guide to Markdown on the Daring Fireball website.

In a recent post to the 3 Engineers blog, they take the usual "Two Step" approach the Zend Framework takes to generating view data (Zend_View + Zend_Layout) and takes it up one more step by using Three Step Layouts with a simple wrapper.

While the Two Step View pattern creates a reasonable paradigm for seperating layout presentation from page presentation, enabling Three-level Inheritance allows for even better separation. In other words, using 3 Step Layouts is a possible and often necessary investment to make when implementing front-ends in Zend Framework projects; they allow fine grain re-usability that provides for a DRYer presentation layer.

They have a three step process you can follow (complete with code snippets) that'll have you working with their 3 layers easily. The wrapper is a sort of "boostrap" for the layout. The nested layout is then pulled into this wrapper (for example's sake, theirs is called "default") and then the view can be served as normal and placed into the content location. There's also a bit of code showing how to switch out the layout if there's ever a need - like different layouts for the admin, user and main parts of your application.

Rob Allen has written up a post today consolidating some of the knowledge he has about using view helpers in the Zend Framework, starting with the basics and some code along the way.

Zend Framework's Zend_View component supports helper methods known as view helpers. [...] typical Zend Framework project using Zend_Application, such as that generated using the zf command line tool, will have a folder called helpers within the views folder for each module. There will also be a helpers folder within the layouts folder too.

He goes on to show how to introduce custom view helpers into your application and how extending the Zend_View_Helper_Abstract class gives you access to many of the common view functions (like "escape").

In the latest post to his blog Rob Allen shows you how to create a custom View object for your Zend Framework application with the help of the Zend_Application component. It uses one of two ways to set up this custom view object - either in the bootstrap or as a custom resource.

Let's say that you want to use your own view object within your Zend Framework application. Creating the view object is easy enough in library/App/View.php along with adding the App_ namespace to the the autoloader in application.ini. All we need to now is get Zend_Application to bootstrap with our new view class. There are two ways of doing this: within Bootstrap.php or using a custom resource.

He includes the code to make it happen both ways - by adding an _initView method in the application's Bootstrap.php file or by creating a new class called App_Resource_View that overrides the getView() method that grabs the custom object.

On the Query7 blog there's a new tutorial that will step you through making a module for the Kohana3 framework - a replacement for the Kohana_View view layer included with the framework.

We will be building a module that replaces Kohana's own view layer (Kohana_View). It will use the PHP template library Twig. We want our own view layer to be API compatible with Kohana's view layer. This will ensure that other modules work out of the box and that the only code the developer will need to alter in their application are the templates (so that they are Twig compatible). No code in any controller will need to be modified.

They lay out the directory structure (dropping all files in /modules) and show you how to enable the module. He talks a bit about what Twig is and shows the code needed to initialize it and configure some of its basic settings. They define the "capture()" method and include a sample of using Twig in your controller.