If you're using Zend Framework 2 (beta 4) and need to easily generate PDFs, and you'd like to generate those PDFs from an HTML template, then boy do I have some good news for you! For those of you who have dealt with generating dynamic PDFs, you know how much of a pain in the ass it can be (e.g. dealing with x, y coordinates, word-wrap (or lack of), etc.). There are a few options out there, some paid, some free, but none of them are as nice as DOMPDF (simple API, powerful, and free). The true power behind DOMPDF comes from rendering standard HTML/CSS files instead of having to write ugly and unmanageable code.

He includes a simple example showing how to use the library to create a basic PDF document (containing an HTML string) and how to port that same thing over to work in ZF2 via a custom DOMPDFModule (a ViewModel). You can find out more about this module in it's README on github.

Unlike Zend Framework 1, the view layer in Zend Framework 2 separates the variables assigned to each view model. This means that when you are in the layout view script, you don't automatically have access to variables that were assigned the the action's view model and vice versa.

He includes snippets of code with an example controller and a sample view that fetches a value from a child ViewModel instance. He also shows how to access layout and configuration values in the view.

The new view layer in Zend Framework 2 can be set up to return JSON rather than rendered HTML relatively easily. [...] Firstly we need to set up the view's JsonStrategy to check to a situation when returning JSON is required and then to render out JSON for us.

This "JsonStrategy" does some of the hard work for you - detecting when the client is requesting a JSON response and looking at the data coming into the view to see if it's JSON. He shows how to implement it in a sample module using the "onBootstrap" module and how to force a return of the JsonModel even when JSON isn't requested (useful for a consistent interface).

This provides MVC applications a natural location for presentation logic and lazy functionality while maintaining the segregation between the layers of responsibility within the code. It allows designers access to data and methods they need, while hiding aspects that aren't needed at view level. [...] Indeed, pretty much any modern Web framework has an understanding of the important segregation of duties inherent within MVC. It is precisely this segregation that leads to a certain greyness around the all-important View, particularly on sites where multiple content items are displayed in different ways.

The tutorial he includes shows how to set up a site with multiple articles per page that can be shown as either headlines or just title text. He talks about three ways to accomplish this - the usual injection of all data into the view and having it handle it there, injecting a model directly and extracting data from it and the ViewModel approach (a combination of the Decorator and Adapter design patterns).