Essentially, what I plan to demonstrate here is how this pattern can be used to build different versions of a given web document on the fly, either for display on a typical computer monitor, or for printing.

This involves the creation of a class to define the styles for both sides - print and screen - and a class that will figure out which of these needs to be applied.

At least at first glance, the definition of the "Stage" pattern seems hard to grasp, which implies that the pattern in question has to be addressed from a practical point of view. In doing so, you'll have a much better idea of how it works, and eventually how it can be applied in concrete cases. [...] Over the course of this two-part series, I'm going to introduce its key concepts, and logically show you how to implement it with copious code samples.

They start by defining a DIV class to act as a foundation for the Stage functionality (with methods to set the ID, the CSS class and the data inside it). They also develop a DivContext class to handle special methods surrounding the inputted DIV. Bringing it all together, they create a default DIV object and pass it into the custom DivContext to get and set the contents of the DIV.

Of course, of the options they gave, "Planning your CMS" came in with an overwhelming lead of 60.5 percent of the votes. Lagging far behind that was "Further Development" and "Database creation". It is good to see that a large majority of the people out there think that taking the time out to plan out the application first is the best way to go. Throwing something together, especially something that can get as complex as a CMS, is a very bad idea.

Be sure and get your votes in on this week's poll that asks which of the given options including "Web and command-line interface" and "Generates a todo list from @todo tags in source") wouldn't be a good option to be added to the phpDocumentor functionality.