Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Alejandro Celaya:
Working with custom column types in Doctrine. Enums.
Jul 30, 2015 @ 08:37:45

Alejandro Celaya has a post to his site showing you how to work with custom types in Doctrine, more specifically with the "enum" type.

Doctrine is currently the most used ORM in PHP. It makes it very easy to work with databases in an object oriented way. It comes with a set of built-in column types that map database types with PHP types. For example, the datetime column type, persists the value of an entity column as a datetime in the database and handles it as a DateTime object when the entity is hydrated.

Type conversions work both ways, so column types take care of casting database to PHP types and vice versa. In this article I'm going to explain how to define custom column types so that we can persist our own objects into the database and hydrate them back.

He points out that, while PHP itself lacks the "enum" data type, you can simulate it with a library like this. He uses this library to create a custom Doctrine object type that mimic enums in the getting and setting of a value to one of a few options. In this case it's values representing the CRUD methods. He shows the code to link the Type back to the Action which then gives it understanding of what the valid enum values can be. He also points out another package that he published recently that takes some of the work out of creating the boilerplate code for the enum.

tagged: package action tutorial enum type doctrine custom library

Link: http://blog.alejandrocelaya.com/2015/07/28/working-with-custom-column-types-in-doctrine-enums/

Paul Jones:
Action-Domain-Responder and the “Domain Payload” Pattern
Oct 01, 2014 @ 10:16:11

Paul Jones has a new post with more information about his proposed "Action-Domain-Responder" design pattern (a replacement for the typical MVC) and suggests a new piece, the Domain Payload pattern. This pattern would use a domain payload object to wrap the data and provide the responder with additional handling and context.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

He shows a code example of this Domain Payload object in action, starting with some typical MVC code and refactoring it along the way into an ADR structure. He shifts from a typical model into a more domain-driven approach and describes the wrapping of the data in the payload, context for the contents (even just a class name helps) and how those relate to the actual output. You can find the resulting code in this example over on Paul's GitHub account.

tagged: action domain responder mvc adr payload wrapper context data

Link: http://paul-m-jones.com/archives/6043

Paul Jones:
Action-Domain-Responder, Content Negotiation, and Routers
Jul 18, 2014 @ 10:17:57

In his latest post Paul Jones comes back to his proposed application structure, the idea of Action-Domain-Responder, and answers some questions about where content negotiation happens and routing.

While talking about Action-Domain-Responder on the Crafting Code Tour, one of the common questions I got was: “Where does content negotiation happen?” My response was always: “Where does it happen in Model-View-Controller?” That opened up a discussion on how content negotiation is a tricky bit that can go in different places, depending on how you want the concerns separated, and is not a problem specific to ADR.

He goes on and tries to answer the question a bit better, pointing out that "it's a problem for everyone" isn't really good enough to take action on. He works through the different pieces of the ADR pattern, trying to reason out where the right fit is. He suggests a "first filter" on the Controller level, more specifically at the Router level. That's not to say that the Router needs to know about content handling, but it does need to know how to pass that information on.

tagged: action domain responder content negotiation routing

Link: http://paul-m-jones.com/archives/6020

How To Display Post Meta Data on a WordPress Post
Jul 11, 2014 @ 10:44:41

NetTuts.com has a a recent tutorial showing you how to show the metadata from a posting in WordPress right along with the other post data.

During the course of the series, one of the things that we did in order to help demonstrate the object-oriented principles as well as some of the features of the WordPress API was build a plugin. Specifically, we built a plugin that allowed us to view all of the post meta data associated with a given post within the WordPress dashboard. [...] Since that particular post was written, I've received a number of different questions one of which has been how do we take the data displayed in the dashboard - that is, the post meta data - and display it on the front end of the web site. In this article, we're going to take a look at extending the plugin such that we can display the data on a single post page.

To display the data, they actually extend the plugin they've already made. They start with some of the issues of this method (and the data itself) that you might run into during the development. They create a "public" directory to store the cached metadata in and a manager class to handle the functionality. The class loads the data and uses output buffering to capture the data. A public hook is defined to call the "display" action on each page load and the results are passed out to the view.

tagged: wordpress metadata plugin extend tutorial action

Link: http://code.tutsplus.com/tutorials/how-to-display-post-meta-data-on-a-wordpress-post--cms-21658

Master Zend Framework:
Change Layout in Controllers and Actions in Zend Framework 2
Jun 27, 2014 @ 10:07:20

Matthew Setter has a new post to his Master Zend Framework site today showing you how to change layouts in controllers and actions for a Zend Framework v2 based application.

In Zend Framework 2, if you want to change the layout just for one action or for every action in a controller, how do you do it? How do you do it without overriding the layout for every action throughout the entire application? In today’s post, based on an excerpt from Zend Framework 2 for Beginners, we see how to achieve both of these requirements.

He talks about the framework's use of the two-step view pattern and what the "template_map" definition usually looks like in a default ZF2 application. He shows three different ways to do the view switching from the controller or action:

  • Override the default layout in your module
  • Override the layout per/action
  • Override the layout per/controller

Each of these comes with a bit of code showing you how to make it work. They move from simplest to more complex, with the layout per controller being the most complex. It's not that it's difficult, it's just that there's more involved to make it work. You can either do it at the controller level or at the module level.

tagged: tutorial zendframework2 controller action change ayout

Link: http://www.masterzendframework.com/views/change-layout-controllers-actions-zend-framework-2

Matthew Weier O'Phinney:
Better Understanding Controllers Through Basic Patterns
Jun 10, 2014 @ 09:53:21

In his most recent post Matthew Weier O'Phinney shares his own spin on the Action-Domain-Responder pattern (from Paul Jones): how the controllers in the ARD setup could be explained as facades.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return. I agree with a ton of it - heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently. Controllers - Actions in ADR - can be explained as facades.

Matthew starts off by defining the Facade design pattern with a quote from the infamous "Gang of Four" book: simply put, a simplified interface to a complex system. He provides a basic example of a facade that wraps some common steps for inserting and logging data with this kind of simplified interface. He applies this to the ADR pattern's controllers, pointing out that it handles a few complex steps "behind the scenes" common to marshaling and managing the request.

For me, thinking of Controllers and Actions as Facades has an additional benefit: it describes rather complex architectural patterns in terms of basic design patterns. I find the more I can reduce the complexity of a definition, the more likely I will understand and use it correctly.
tagged: controller designpattern adr action domain responder facade

Link: http://mwop.net/blog/2014-06-09-controllers-as-facades.html

Paul Jones:
Refactoring To Action-Domain-Responder
Jun 06, 2014 @ 10:06:15

Paul Jones has a new post to his site today with a more in-depth look at his proposed "Action-Domain-Responder" design pattern and how to refactor an application, based on some with with the Aura framework, to use it.

The v1 version of the Aura framework includes a controller to handle web assets. The idea for this controller was that an Aura package might have images, scripts, and stylesheets that need to be publicly available, but in development you don’t necessarily want to copy them to a public document root every time you change them. [...] That v1 version is a mess. The Controller handles the response-building entirely, and there is no Model separation at all. Let’s try refactoring it to an Action-Domain-Responder architecture and clean it up some for a v2 version.

Associated code it just linked to, but he does summarize the steps needed to make the transition: extract the domain logic, move responses to a separate class and rename the controller to an action. He also shows how making this separation makes testing easier and links to examples of tests for each. He finishes the post with two final notes about the refactor. One points out that this method isn't the only way to handle this architecture shift and that the action returns a responder, not a response object.

tagged: action domain responder designpattern architecture refactor

Link: http://paul-m-jones.com/archives/6006

Stephan Hochdörfer:
Controller classes vs. Action classes
May 19, 2014 @ 10:52:31

In this new post to his site Stephan Hochdörfer covers some of his own thoughts about the recently proposed application structure from Paul Jones, the "Action-Domain-Response" pattern. In this post Stephan compares the typical controller classes with an action class.

First of all I do have the feeling that controller classes make it harder to structure your logic. I have seen a lot of "God Controllers" that do a shitload of stuff. Stuff that is not really related to each other. [...] action classes tend to be rather small, typically less than 100 loc for us. That also helps a lot when trying to understand what`s going on. I am aware that there are developers out there who are afraid when it comes to dealing with a lot of classes. [...] That`s another bonus point for action classes: It is easier to search for a class name than a method name in most IDEs.

He goes on to talk more about "God controller" classes, their dependencies and how that compares to action classes only taking in what they need. He touches on the reusability of action classes as opposed to controllers and how they come in handy for storing common logic.

tagged: controller action class compare logic dependency

Link: http://blog.bitexpert.de/blog/controller-classes-vs.-action-classes

An Introduction to the Front Controller Pattern, Part 1
Jul 31, 2012 @ 13:31:12

If you've done any work with PHP frameworks, the concept of a "front controller" should be a familiar one. If you haven't, the idea might be new to you and PHPMaster.com has started off a series that will introduce you to the basics of the Front Controller design pattern in a few different parts.

Some are now grumbling about newer concepts that have recently made inroads in day-to-day PHP development, saying Front Controllers are a redundant “reinvention of the wheel” which should be discarded ipso facto. [...] In this two-part article I’ll be exploring in depth a couple of straightforward approaches that you might find appealing, especially if you’re trying to implement an expandable front controller from scratch without sweating excessively during the process or having to cope with the burdens of a bloated framework.

This first part of the series introduces you to some of the basic concepts of routing and URL handling and shares the code for a basic front controller. It parses the URL and sets up the controller and action to hand the request off to. Also included is the contents for the .htaccess file you'll need to include to route all requests back through this controller instance.

tagged: frontcontroller designpattern introduction routing controller action


Lorna Mitchell's Blog:
Building A RESTful PHP Server: Routing the Request
Jan 23, 2012 @ 11:14:11

Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

tagged: restful server tutorial request routing controller get post action