Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

In a post to his site Paul Jones shows how an implementation of his proposed Action-Domain-Responder pattern might look when implemented with Slim, a popular PHP microframework.

I’ve had a warm place in my heart for Slim for a long time, and especially so since recognizing the Action-Domain-Responder pattern. In this post, I’ll show how to refactor the Slim tutorial application to ADR.

One nice thing about Slim (and most other HTTP user interface frameworks) is that they are already “action” oriented. That is, their routers do not presume a controller class with many action methods. Instead, they presume an action closure or a single-action invokable class. So the Action part of Action-Domain-Responder already exists for Slim. All that is needed is to pull extraneous bits out of the Actions, to more clearly separate their behaviors from Domain and the Responder behaviors.

He then works through each piece of the example application, first extracting out the Domain logic then building a Responder to handle the user interface functionality. He combines them to replace the current functionality, pointing out that the responder can now be tested separately from the user interface (templating system).

Now, for a simple case like this, using ADR (or even webbishy MVC) might seem like overkill. But simple cases become complex quickly, and this simple case shows how the ADR separation-of-concerns can be applied as a Slim-based application increases in complexity.

Paul Jones has a new post on his site sharing some of his thoughts about the placement of domain logic and email templates in an ADR (Action/Domain/Responder) structure. The post is an answer to a recent question he received asking how to organize emails being sent by service classes.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.

In this recent post to his site Paul Jones suggests that "action injection" in PHP applications should be considered a "code smell" (that is, a bad practice that could indicate that the controller class is doing too much).

Circumstance has conspired to put Action Injection discussions in front of me multiple times in the past few days. Having seen the approach several times before, I have come to think that if Action Injection is the answer, you might be asking the wrong question. I find it to be a code smell, one that indicates the system needs refactoring or reorganizing.

He first covers what "action injection" is and provides an example of how it would fit in with the use of a dependency injection container. He also points to some of the frameworks that currently support this functionality natively. With that defined, he then moves into the main idea of the post - that using functionality like this is a "code smell" that could signal something that is in need of refactoring. He then provides some suggestions on things to change and mental shifts in thinking about how your application is organized. He finishes by pointing to the Action-Domain-Responder pattern as a way of implementing this and how single-action controllers can help.

In response to a recent post from Anthony Ferrara about MVC Paul Jones suggests that Anthony's view that it and related structures "all pretend to be application architectures" is false.

The central mistake I think Anthony makes is near the end of this post, where he states (in talking about MVC, ADR, et al.) that “All Pretend To Be Application Architectures.” That assertion strikes me as incorrect. While it may be that developers using MVC may mistakenly think of MVC as an application architecture, the pattern description itself makes no such claim. Indeed, Fowler categorizes MVC as a “Web Presentation Pattern” and not as an “Application Architecture” per se. [...] Fowler’s categorization and description of MVC define it pretty clearly as a user interface pattern. ADR, as a refinement of MVC, is likewise a user interface pattern.

He goes on to talk more about the ADR (Action-Domain-Responder) pattern, how it's more of a user interface pattern as well and how that relates to using it for HTTP requests. He suggests that the definition from Anthony may be a bit too broad and proposes the alternative "All Are User Interface Patterns, Not Entire Application Architectures" to be a bit more specific.