On the CodeWall blog they've posted a tutorial showing how to create a single action controller in a Laravel-based application to isolate functionality that can be called directly with no method required.

There are some magical functions in PHP, and __invoke is one of them.

Through this __invoke method, we can create classes with just one function __invoke in them, and whenever their object is called it will directly call the __invoke method, it means you don’t have to manually say $obj->someFunction() .

The post starts by talking about the Single Responsibility Principle (SRP) and how having an isolated controller with just an __invoke method. It then walks you through the implementation and how to use a controller like this. In their example they show how to use it to create "post" records (like for a blog). The post also includes some of the drawbacks of using this kind of controller including the fact that you cannot use resource routing with it.

On the TutsPlus.com site they've posted a tutorial for the Laravel users (well, Eloquent users) out there showing the use of mutators and accessors in this ORM package.

In this article, we'll go through mutators and accessors of the Eloquent ORM in the Laravel web framework. After the introduction, we'll go through a handful of examples to understand these concepts.

In Laravel, mutators and accessors allow you to alter data before it's saved to and fetched from a database. To be specific, the mutator allows you to alter data before it's saved to a database. On the other hand, the accessor allows you to alter data after it's fetched from a database. In fact, the Laravel model is the central place where you can create mutator and accessor methods. And of course, it's nice to have all your modifications in a single place rather than scattered over different places.

The tutorial starts with the creation of a simple "Post" model to use in the examples via the artisan command. It also includes the full code to flesh out the class to define a mutator and accessor for the "name" property. It then talks through what these two methods do and how they're called automatically when the property is accessed/updated. It's then put to use in a controller showing each of them in use to work with the published_at date value.

On his Medium.com site Peter Lafferty shares a method he uses for test-driven development on Silex controllers, something made difficult by the way the dependencies are injected into the controllers automatically.

“TDD it’s so easy” that’s what they tell us. There’s not trick to it, it’s just a simple trick. This article shows one way to unit test Silex controllers.

The way to implement TDD on a Silex controller is composition, low coupling and dependency injection. At its most basic a Silex controller has no relationship to Silex. However its easy to end up with controllers tightly coupled to the Application and Request classes.

He talks about the two main issues around effective TDD with Silex: the way the dependency injection controller is injected automatically and how the controller "resolver" enforces certain method names. He's figured out tricks to help get around these issues, though. The first involves creating the controller as a service and the second is to only pass the parts of the request the method needs. He includes code showing this in action to help clarify his points.

In a post to his site Jen Segers says "goodby to controllers" in favor of request handlers. Request handlers are a concept similar to the ideas in the ADR pattern but are defined a bit differently.

If you have worked on large applications before, you might have noticed that you end up with bloated controllers sooner or later. Even if you use repositories or service classes to extract logic from the controller, the amount of dependencies, methods and lines of code will grow over time.

Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action.

He suggests using invokable classes to build out request handlers in your PHP code, making use if the magic __invoke method to make them callable. He gives a "hello world" kind of example and talks about how Laravel and Slim already implement this idea in their routing. He then looks at how these responders help you adhere to the Single Responsibility Principle (part of SOLID) and how they make the code easier to test and simpler to refactor.

In a new post to his site Paul Jones shares a conversation he had about handling domain exceptions in controllers and if it was a good practice or not.

A few months ago I had a great email conversation with a correspondent about how to handle business logic exceptions in his controller code. [...] If you find yourself in this situation, the first question to ask yourself is, “Why am I handling domain exceptions in my user interface code?” (Remember: Model-View-Controller and Action-Domain-Responder are user interface patterns; in this case, the user interface is composed of an HTTP request and response.) Domain exceptions should be handled by the domain logic in a domain-appropriate fashion.

He shares the original email (shortened) where they asked their question and outlined their current situation and setup. He points out that the point the other person made about not feeling right to thrown domain exceptions and having the controller handle them is a good path to follow but to take it even further. He suggests modifying the response to the domain logic to be a "domain payload" instead of an exception and then have the controller use that (getting its status) to determine how to proceed. This can prevent the need to catch random exceptions and provides more consistency to the overall flow.

On the Zend Framework blog there's a new post showing you how to implement a JSON-RPC interface with zend-json-server, a package from the Zend Framework 2 set of components.

zend-json-server provides a JSON-RPC implementation. JSON-RPC is similar to XML-RPC or SOAP in that it implements a Remote Procedure Call server at a single URI using a predictable calling semantic. Like each of these other protocols, it provides the ability to introspect the server in order to determine what calls are available, what arguments each call expects, and the expected return value(s); JSON-RPC implements this via a Service Mapping Description (SMD), which is usually available via an HTTP GET request to the server.

The article provides a basic example of the creation of a service that handles GET requests and gives back a service mapping description. Building on this, they show how to integrate it into an application that makes use of the zend-mvc structure. They implement a "JsonRpcController" using the same methods as before. Finally they show an example of performing JSON-RPC handling in middleware, outputting the same output as before based on the data in the $response variable.

On the Laravel News site there's a post detailing some of the updates made to session and controller handling in v5.3 of the framework. It mostly revolves around how the middleware handling changed on each request from v5.2.

Back in laravel 5.2, a developer was able to interact with the session directly in a controller constructor. However, this has changed in laravel 5.3.

The difference between how the 5.3 & 5.2 handle an incoming request is that in 5.2 the request goes through 3 pipelines: global, route and controller [...] In 5.3 the request goes through only 2 Pipelines: global and route/controller (in one pipeline).

The post includes a quote from Taylor Otwell (creator and lead developer of the framework) about why this change was made. Then it shows an alternative to directly accessing this session information in your controllers: a Closure-based middleware in the constructor to execute your checks.

In a post to his site Stefan Koopmanschap takes a look at the technical term "command" and tries to clear up some of the confusion around its use and how it differs from the idea of a "controller".

A couple of weeks ago while walking towards lunch with Jelrik we were having a bit of a discussion about the use of the term Command. Not long before that, Jelrik had asked a question about naming of Commands in our Slack channel, which led to some confusion.

He starts off by defining what a command is and why it's called a "command" instead of a controller (hint: it "just works" with the Symfony Console). He then gives an example of a command in a Symfony bundle structure and how a CLI "controller" can extend the Command and automatically be integrated into the command structure.

Loïc Faugeron has made a new post to his site talking about moving towards CQRS and Command Bus architecture in PHP applications.

By following the Command / Query Responsibility Segregation (CQRS) principle, we separate "write" logic from "read" logic. This can be applied on many levels, for example on the macro one we can have a single "Publisher" server (write) with many "Subscribers" servers (read), and on a micro level we can use this principle to keep our controllers small.

However, transitioning from a regular mindset to a CQRS one can be difficult. In this article, we'll explore the "Command Bus" pattern, to help us to get the Command (write) part right.

He starts with an example of a "create profile" happens and all logic lives in the controller. He then gets into the basics of the Command Bus handling and how the concept of "middleware" relates. He then shows how to migrate over to the Command Bus handling in his controller example, creating a CreateNewProfile command (with unit tests) and its handler. He then refactors the controller to put it to use. He points out that the initial version is tightly coupled to Doctrine so he refactors it too via some simple interfaces.

The Inviqa blog has posted a tutorial that gets in to the details of using PSR-7 compatible functionality in Symfony through the introduction of middleware into your application.

The PSR-7 standard, which describes common HTTP message interfaces, is a big step towards interoperability across different PHP libraries. The standard was introduced not long ago, but you can already use libraries compatible with this recommendation within your Symfony-based application.

[...] A step toward more homogeneity was achieved when the PHP Framework Interop Group accepted PSR-7 in May 2015. This recommendation describes common HTTP message interfaces. The biggest benefit the PHP community gets from the standard is a potential for interoperability across different PHP libraries. You can already use libraries compatible with this recommendation within your Symfony-based application thanks to the Symfony PSR-7 Http Message Bridge.

The tutorial then shows how to use this message bridge to convert the current Symfony HTTP request and response instances over to follow the PSR-7 structure (essentially a wrapper around it). They then show how to use this functionality in a simple Symfony controller, taking advantage of an event listener to automatically convert the request based on type hinting in the controller method. Finally they talk about middleware, what they are and how they fit into the flow of a web request/response structure.