As Matthew Weier O'Phinney has posted, the PSR-7 PHP-FIG proposal is in the voting stages. The PSR-7 standard defines a unified interface for working with HTTP requests and responses.

As of a short bit ago, PSR-7 (meta) — HTTP Message Interfaces — is now in the voting phase! If you are a voting member of PHP-FIG, I urge you to read the specification and meta document now, and cast your vote accordingly.

I have written previously on the need for HTTP message abstractions, and also detailed how PSR-7 works. Those posts are still valid (I've kept the latter updated with all changes!). Since the review period, my sponsors and I have been looking over feedback and comments to see if any changes were needed. Fortunately, we've not found any substantive changes were really necessary; we have, however, made a few clarifications.

He clarifies some things around:

• why base path concerns are not represented in the ServerRequestInterface or UriInterface
• a note that UriInterface::getPath() MUST return the string "/" if the path is empty
• that UriInterface implementations MUST percent-encode reserved characters in paths and query strings, per RFC 3986
• why StreamableInterface is mutable, and provided guidelines to implementors and consumers regarding how and when to use writable streams
• the addition of several sections to the meta documentation detailing solutions to common stream-based concerns

He also gets into a bit more detail about streams, base paths and some of the overall outcomes if the PSR-7 proposal passes (which it looks like it will so far).

If you adopt PSR-7, will you need to change your code? Almost certainly. The goal of PHP-FIG is to improve interoperability between projects, and PSRs typically attempt this via codification of what member projects are already doing.

In the second part of their look at the Stage design pattern today, DevShed moves up from the previous article to implement a more "real world" example of the Stage pattern in action.

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.

In the second part of their look at the Stage design pattern today, DevShed moves up from the previous article to implement a more "real world" example of the Stage pattern in action.

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.

Back with another of their design patterns articles, DevShed looks this time at the Stage pattern - a flexible pattern that allows your application to adapt to requests.

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.

Back with another of their design patterns articles, DevShed looks this time at the Stage pattern - a flexible pattern that allows your application to adapt to requests.

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.

The International PHP Magazine is back this week with the results from their latest user poll that asked the question "Which Stage Comes First in the Development of the Basic CMS?"

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.

The International PHP Magazine is back this week with the results from their latest user poll that asked the question "Which Stage Comes First in the Development of the Basic CMS?"

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.