Mathias Noback has posted the next part of his command bus in PHP series today with a few suggestions about event handling and when it's a good idea to dispatch them.

It was quite a ride so far. We have seen commands, command buses, events and event buses. We distilled some more knowledge about them while formulating answers to some interesting questions from readers.

In this new post, his focus is on collecting the events that happen as a part of the command's execution. He uses his "UserSignedUp" event his his previous example and a "send welcome email" handler to show why it may not be the best idea to execute all events simultaneously. Instead, he recommends making use of event collections (a feature his SimpleBus library supports) to define "providers" that can collect the events that need to happen and delegate the execution of them one after the other. Example code is included all through the post of events, providers and commands that make use of this idea.

Matthias Noback is back with another post in a series looking at using a command bus to execute more complex code in somewhat of an isolation from the rest of the application. In this new post he moves on to some of the secondary tasks that happen inside the commands and how those relate to event handling.

In the previous posts we looked at commands and the command bus. Commands are simple objects which express a user's intention to change something. Internally, the command object is handed over to the command bus, which performs the change that has been requested. While it eventually delegates this task to a dedicated command handler, it also takes care of several other things, like wrapping the command execution in a database transaction and protecting the original order of commands.

He gets into some of these secondary tasks inside of the commands themselves - smaller actions that need to be done as a part of the execution of the command as a whole. He points out that it's tempting to do everything inside the command, but that it can lead to maintenance issues down the line. He suggests that the command shouldn't perform these tasks at all. They should be handled by an event system that uses event objects to pass off responsibility for performing actions to other objects (for example, handling the post-signup process once a user is created). He's done some research on some event dispatchers currently available but found them lacking in one way or another. Instead he opted to integrate one into his SimpleBus library (EventBus) to provide an integrated way of handling these secondary events. An example of it in use is also included.

On the Qafoo blog today Tobias Schlitt talks about dynamic dispatch, what he calls a "fundamental concept of OOP" to help provide clean, clear interfaces in the code.

I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.

He explains the concept of "dynamic dispatch" by starting from the beginning...with procedural PHP code. He looks at the usual flow of this kind of application that call shared functions in a "top down" fashion. He looks at what would happen if new logging needs were introduced (use a new method? patch the current one?) and the dependencies that can be introduced because of it. With this in mind, he continues and talks about how the "dynamic dispatch" happens during the code execution, splitting the log request based on the information it's given instead of different implementations for each. He points out that using a trait doesn't allow for this abstraction and instead embeds the code into the class itself, re-introducing the original problem.

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

In his latest post Nikita Popov talks about routing and regular expresions. He also shares some work he's done to create a fast request router using them in "userland" code instead of a C extension.

Some time ago I stumbled on the Pux routing library, which claims to implement a request router that is many orders of magnitude faster than the existing solutions. In order to accomplish this, the library makes use of a PHP extension written in C. However, after a cursory look at the code I had the strong suspicion that the library was optimizing the wrong parts of the routing process. [...] To investigate the issue further I wrote a small routing library: FastRoute. This library implements the dispatch process that I will describe below.

He includes some benchmarks against the results from a C-based routing engine showing his solution performing slightly better. What he's really talking about, though, is the dispatch process in general, not just his implementation. He talks about "the routing problem" many engines face - having to loop through a potentially large set of routes to find a match. He offers an alternative using regular expressions and compiling all of the routes down into one large expression. He includes a simple implementation of the method and reruns the same benchmarks with some different results. He offers one potential solution for speeding it up using "chunked expressions" to break it down into more manageable matching. He includes benchmarks for this last solution as well, showing a slight improvement.

PHPMaster.com has posted the second part of their series introducing you to one of the more popular design patterns in PHP frameworks right now - the Front Controller pattern. Part 1 introduced some of the fundamental concepts and this new article expands on that, getting more into the request and reponse handling process.

One of the best things about front controllers is that you can keep them running as tight structures, just routing and dispatching incoming requests, or you can let your wild side show and implement a full-fledged RESTful controller capable of parsing HTTP verbs, accommodating pre/post dispatch hooks, and the like, all behind a unified API. [I'd like to show] you how easy is to deploy a small, yet extensible, HTTP framework capable of putting to work a front controller along with the ones of a standalone router and a dispatcher. Plus, the whole request/response cycle will be independently handled by a couple of reusable classes, which naturally you’ll be able to tweak at will.

He bases his examples off of the EPHPMVC project, showing how to implement a RequestInterface, ResponseInterface and link them together with a RouteInterface and use the DispatcherInterface to handle the requests. The front controller is then created with its run() method and an instance is created in a main PHP file that all requests are routed through.

In his latest post Matthew Weier O'Phinney introduces you to the new init() method in the Zend Framework 2 controllers and how it differs from the one in version 1.

In Zend Framework 1, controller's had an init() method, which was called after the controller was instantiated. The reason for it was to encourage developers not to override the constructor, and thus potentially break some of the functionality (as a number of objects were injected via the constructor). init() was useful for doing additional object initialization. [...] But this feature is missing from ZF2; how can we accomplish this sort of pattern?

In Zend Framework 2, there's no Controller constructor by default anymore, so you have to do things slightly differently. He shows you how to use the event manager to simulate the same thing, attaching an event to the "dispatch" of the controller to do the work. He came back and updated the post with a second method that could do the same thing - using the ServiceManager from inside a module and attaching the event that way.

Rob Allen has a new post to his blog today looking at bootstrapping specific modules in a Zend Framework 2-based application without having to do the entire set.

Following on from the discussion on modules, we can hook into the event system to do module specific bootstrapping. By this, I mean, if you have some code that you want to run only if the action to be called is within this module, you can hook into the Application's dispatch event to achieve this.

He starts with an example of a basic module (Simple/Module.php) and shows how to define an "onBootstrap" method that calls the "onDispatch" method (when hooked to the event manager) to do some module-specific bootstrap operations. The RouteMatch feature is used to ensure that you're in the right controller/namespace combo to use the module.

In a new post to his blog today Matthew Weier O'Phinney takes a look at micro MVC frameworks and how, with just a bit of lightweight code and pieces of the Zend Framework, creating one is dead simple.

My job is great: I get to play with technology and code most days. My job is also hard: how does one balance both functionality and usability in programming interfaces? [...] One interface I've been toying with is inspired by two very different sources. The first is PHP's own SoapServer API (which we use already in our various server components); the other was a discussion I had with Fabien Potencier (of Symfony fame) a couple years ago, where he said the goal of Symfony 2 would be "to transform a request into a response."

The result is a simple Dispatachable interface that acts as the lowest level to build the whole MVC on top of. He illustrates with a micro MVC example that uses the Dispatchable interface to create a Dispatcher class to handle the incoming requests and attach various endpoints for handling. An example of it in use is also included.

In this new post to the Zend Developer Zone, they point out a workflow diagram Polley Wong has come up with showing how the Zend Framework's dispatch system works (request handling).

I've been researching Zend Framework lately and was curious about what's actually happening behind the scene of the whole dispatch process. Inspired by Thorsten Ruf's (zenddispatch_en.pdf) clear and beautifully presented workflow, I decided to go a step deeper and crawl Zend Framework's code. I came up with my own version of the flexible yet complicated workflow.

You can check out this new PDF here. It diagrams out an overall view of the request handling, a look at what happens inside the front controller including components like the Controller Dispatcher, Action Controller, Action Helper Broker and Response Object.