on 11 November 2013 by in
In the lessons learned post a few weeks ago, I wrote about how Aura was born of the idea that we could extract independent decoupled packages from Solar, and how in doing so, we discovered that some of those extracted packages themsleves could be further split into independent pieces.
The last example of this was how we extracted Aura.Dispatcher from three separate packages. Today, I’m going to talk about how the Aura.Web v2 package has been slimmed down as a result of Aura.Dispatcher being created. (Incidentally, Aura.Web v2 is also PHP 5.3 compatible!)
Aura.Web v1 took the parts of Solar related to web controllers and combined them into a single independent package. The v1 package contains …
a ControllerInterface along with an AbstractPage controller object to provide a base controller for web actions;
a Context object to represent the web request for the controller;
a Response data-transfer object to represent the web response from the controller;
an Accept object to deal with content-type, language, charset, and encoding negotiation;
a segregated SignalInterface and a bare-bones Signal implementation to handle controller hooks like pre-action, post-action, etc.
As I said in the peek at Aura.Sql v2 post, when you are used to certain things always being bundled together, it can be hard to see how they could be separated. In the Aura.Sql case, we moved some of the functionality around so that connections, schema discovery, and query building could become independent of each other; the no longer needed to be provided simultaneously.
In the Aura.Web case, it turns out extracting Aura.Dispatcher was the key to reducing the Aura.Web package contents. With Aura.Dispatcher, any object can be a controller, since it can dispatch to any method on any object (as well as dispatching to closures). In turn, there is no more need for the Aura.Web package to provide a base controller with interfaces for various implementations. Instead, you can dispatch to any object you like, with the dependencies you prefer, as your controller. That controller object can be implemented at the framework level, or in a separate package or bundle.
As a result, this means that web-specific request and response objects can be in their own package independent of any particular controller implementation. The Aura.Web v2 package contains only those request and response objects.
First, the Aura.Web v2 Request object is not an HTTP request
representation. It contains copies of
$_SERVER, etc., that are
clearly not part of an HTTP request proper. More strictly speaking, the
Request object represents the web request execution environment of PHP.
The Request object has various sub-objects representing all of the PHP superglobals, along with objects for …
The Request object can be used in any controller (or any other object, really).
As with the Request object, the Response object only describes the web response, and is not an HTTP response proper. It has sub-objects for …
Once you have built a Response object with any controller of your preference, you can send it with any HTTP mechanism you like, including plain PHP.
Whereas the v1 package included controllers, renderers, and other functionality, the Aura.Web v2 package provides only Request and Response objects. These objects are independent of any particular controller system, and independent of any specific HTTP delivery mechanism, which means they can be used in any new or existing codebase without introducing other dependencies.
By extracting functionality to independent packages, Aura v2 continues to make good on its core promises. If you like clean code, fully decoupled libraries, and truly independent packages, then the Aura project is for you. Download a single package and start using it in your project today, with no added dependencies.blog comments powered by Disqus