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.

One of the many things you don't often do with PHP (actually, I'm not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.

He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a ".pid" file so the system knows about it and then, of course, have the child script do something.

With the theory heavy portion of the series out of the way, we can begin to explore the various implementation possibilities. In this part, we will examine implementing Asynchronous Processing using a child process, i.e. a separate PHP process we create from our application during a request. We'll analyse this implementation option before introducing the source code so we may understand its advantages and disadvantages.

He looks at both the advantages and disadvantages of processing with child processes and suggests a method to get a handle on the processes rather than just spawning new processes - forking. Some basic code examples are included, using the popen function to open the new child process and a Zend Framework example.

In trying to get more out of our webservers using a Lighttpd and PHP-FastCGI setup, I've come across some major issues that make it difficult to use. I hope this post will warn people of some of the bugs they might encounter and workaround that might need to be implemented until some of these are fixed.

He ran up against two problems - that the parent PHP-CGI process spawns off the configured number of children correctly but with the lighttpd server is killed, they don't get released and that, once you hit full capacity for the PHP backend lighttpd starts serving up 500 errors.

In the comments for the post several others have offered some advice on things that might help (like different config settings and even using XCache to prevent the 500s issue from coming up again).

The Doctrine library comes with a feature called nested set, which makes saving trees in a database easy. However, it's quite easy to accidentally cause a lot of extra unneeded queries if not being careful. Here are some pointers to keep in mind while working with the nested set, and some example queries to make understanding it easier.

He gives an example, showing how to get rows from the database - parent and child - and some optimization tips to keep things light. There's also some pros and cons included for doing it either way (the standard fetching or using the more optimized versions).

If the software calls for only 2 levels of categorization (Parent and Child only), a simple nested for loop will suffice. However, software requirements change and you'll soon find yourself up shit creek without a paddle if you need to support 3 or 4 levels of nesting. [...] To those who's training is less formal (most web developers I meet have practical training, not formal), I'll help you out: Tree Traversals (or if you are completely lost, Recursion).

He creates a recursive function that, when passed in a category set with different types in it, can handle each of them and then calls itself again with the new child data. His sample code creates url out of a set of categories.

Now that you know what will be treated in this fourth chapter of the series, it's time to learn how to declare and implement public and protected methods with PHP 5 classes. Of course, as always I'm going to address this useful topic by using a hands-on approach, which means that there's a bunch of code samples ahead, waiting patiently for you.

They talk about calling methods globally first and then move into the keyword restrictions. They show the difference between a public method/variable and a protected one, including how to get at the protected members from a child class.

In this last chapter of the series, I'm going to teach you how to handle the child nodes of an XML document by way of two simple methods, called hasChildNode() and removeChild() respectively. So let's not waste any more time in preliminaries and learn how to use them in a helpful way.

They review some of the concepts mentioned previously before moving ahead to the use of the hasChildNodes and removeChild methods to check for children and get rid of only certain ones.

PHP has a function serialize, which can create a hash from any type of variable, scalars, array, but objects as well. Using the unserialize function, PHP can recreate the variable from the serialized hashed. If we look at how an object is serialized, we see only the properties and the class name are stored.

His method allows for class manipulation via changes to the serialized class information (like changing the value of the name parameter). His "casttoclass()" function makes changing this value simple.

I won't rehash all of the arguments as you can quite easily find out my full thoughts by previous posts and on that mailing list thread. To put it simply I feel that somehow there needs to be a way to call methods in a parent class without losing the ability to reference back to the original called static.

He gives an example of what he's talking about (code) and, to help further his cause he's created three patches to make it work how he'd like.