As server-side web developers, we tend to think of our templating system as providing the View layer in a Model-View-Controller architecture. I have recently come to the conclusion that this is an incorrect approach. Instead, we need to think of the HTTP response as the View.
When an HTTP client makes an HTTP request, what does it get in return? It does not receive only the body of the HTTP response. The client receives the body and the headers of the HTTP response. The response as a whole is what the web application delivers as its presentation to the client.
Templating systems, as far as I can tell, deal only with the body of the HTTP response. In practice, the rest of the response is generally handled by the Controller; for example, setting the status, setting cookies, and modifying headers.
Let’s say we accept the idea that the HTTP response is the View (i.e., the presentation that is delivered to the client). If we accept that idea, then for a clean separation of concerns a la SeparatedPresentation, we need to combine both the template work and the header work into their own layer. That layer needs to be completely separated from the Controller and Model.
Thus, anything that deals with the response, including the setting of headers, should be considered the View layer. If you are setting headers in a Controller, you are losing that clean separation of concerns. To remedy this, your Controller needs to hand off to a layer that builds the response on its own; this is the proper place for the tempalting system to be invoked, not the Controller.
In summary: the template is not the View. The response is the View. We should separate our concerns accordingly.
If you like the line of thinking presented here, please check out the Action-Domain-Responder refinement of the MVC pattern. It’s still a work-in-progress so be sure to leave your comments and criticism either here on this blog or as a new issue at Github.
This article about being able to be graduated by university applies to developers, too: begin by substituting “your first few projects” for “high school” and “the development community at large” for “college”.
You may think you are smart because you got high grades in high school, but the reality is that you’re not really as smart as you think you are; you just went to a high school where everyone was stupid so you just seem smart in comparison.
Compared to the much smarter students who normally attend our college, you’re going to find yourself at the bottom of the class. While the smarter students find passing their classes to be relatively easy, and even fun, that’s not going to be the case for you. For you, college will be hard work, difficult and unpleasant, if you want to graduate.
You have the ability to graduate if you put in the effort, and take advantage of the extra tutoring services we have available for you, but college will not be a fun experience for you. I still recommend that you attend our college, but if you think that you’re not willing to work very hard, to study while the smarter kids are having fun at beer parties, then you would be better off not attending our college.
(Title quote from Moses Ngone.)
A nice note from Brett Bieber:
Five years ago today, a group of PHP framework thought leaders came together to discuss interoperability and coordination. We met in a small room, talked our issues out together, agreed and disagreed respectfully.
At the time we were labeling our cause: “PHP Standards and Best Practices for PHP 5.3+ Frameworks and Libraries”
For better or worse, the group has evolved since then, but my hope is for continued success and interoperability.
Congrats to all the members, new and old.
Via the PHP-FIG Google Group.
I’ve been asking for feedback on the Action-Domain-Responder pattern, a refinement of MVC, to discover how it’s being used in the wild already, and to solicit criticism of the pattern to find weak points.
The key points of Action-Domain-Responder:
Instead of a controller class with many action methods, each Action is its own class (or closure, like with Slim).
The Action interacts with the Domain (model), and feeds data to a Responder (view).
The Responder is entirely responsible for building the response, including all headers as well as the body of the response. This means that in ADR, the template is not the view; the response is the view.
Stephan Höchdorfer has been using single-Action classes for a while now. Here is my summary of his article:
“we are using action classes in our application framework for almost the last decade”
“action classes tend to be rather small, typically less than 100 loc for us”
“another bonus point for action classes: It is easier to search for a class name than a method name”
“Controllers tend to have a lot of dependencies. … people came up with a few “creative” solutions for this problem, mainly the creation of lazly loaded dependencies”
“action classes depend on what they really needed. Typically that’s just a few services for a single action. Again that makes the code way easier to understand and easier to test.”
“Action classes in contrast to controller classes can be reusable.”
Those were the highlights for me; you should read the whole essay to find your own: http://blog.bitexpert.de/blog/controller-classes-vs.-action-classes
In addition, please write up your own commands and criticism regarding Action-Domain-Responder, so that I can improve the offering as much as possible.
The Business and the Programmers want the same thing. They want the same thing: to deliver a more predictable stream of important features that will make the market happy—or, at least, knowing the fickle market, that will risk disappointing them the least.
This. Is. Glorious.
The Business and the Programmers needs to agree on two things, each conceding a key point to the other. The Business needs to agree that the Programmers have heretofore gone more quickly than they really can, that they cannot sustain this pace, and that to do so merely hastens the ultimate decline of the entire product line, and perhaps the company. The Programmers need to agree that the Business has a legitimate need to deliver more features, that everyone’s livelihood depends on this, and that trying to ask for more than the Programmers can deliver forms part of the Business’s “job”, as it were. The market compels them to do this. In this equation, the Programmers have the responsibility to do whatever they can to maximise their ongoing delivery speed, and that includes regular, agreessive refactoring.
Finally, both the Business and the Programmers have to agree that they have wasted too much time arguing about this and need to move forward. They want the same thing! They can have it!
Aura.View 2.0.0-beta1 is a reduced implementation of the v1 View package. …
The templates can still be include files, but (and this is new) they can also be closures. This means that you can completely avoid the file system for templates if you like. …
There are no longer any escapers or helpers included, although the package does include a bare-bones HelperRegistry so you can add your own callables as helpers.
Aura.Html 2.0.0-beta1 contains a collection of helpers extracted from the v1 Aura.View package. These helpers are completely standalone and are not dependent on any particular view system: instantiate a HelperLocator from the Aura.Html package and you can use the helpers from any PHP code. …
All of the HTML5 input types are supported. This makes building form elements very easy, especially since the data structure for each element is just an array. Any library that can generate the recognized array structure can be used to feed the form input helpers. …
In addition, [Aura.Html] includes a powerful escaping mechanism derived from ZendEscaper and modified for conceptual integrity with the rest of Aura. The Aura.Html Escaper exposes static methods to make escaping as non-verbose as possible.
Read the whole thing at http://auraphp.com/blog/2014/05/15/view-html-2beta1/!
Just some short updates today, since last week was so very busy:
1. The “Action-Domain-Responder” (née “Action-Domain-Response”) refinement of the MVC pattern has received some positive criticism and attention. In addition to example code updates, I have added responses (heh) to critiques regarding the Resource-Method-Representation pattern, and will soon be adding a response regarding “Entity-Interactor-Boundary” (aka “Entity-Contol-Boundary”). Many thanks to the commenters who recognized that they were already doing something along the lines of ADR; this helps to validate the pattern as something that already occurs “in the wild.” If you like the pattern offering, please star it at Github.
3. It looks like the next two Aura v2 releases will be Aura.View (the view system, specifically the “reduced” branch) and Aura.Html (the HTML helper collection that can be used by any view system). I’ve done a lot of work on them in the past few days and they’re beginning to feel like they’re ready.
UPDATE: This article has been updated into a working draft, with PHP-based example code, at http://pmjones.io/adr.