Fabien Pontencier has made an official announcement about a move to make the PHP Security Database the Symfony project started over a year ago. In the announcement he talks about the move to (hopefully) make it more widely adopted - pulling it out from under the Symfony namespace and into the FriendsOfPHP organization.

A year and a half ago, I was very proud to announce a new initiative to create a database of known security vulnerabilities for projects using Composer. It has been a great success so far; many people extended the database with their own advisories. As of today, we have vulnerabilities for Doctrine, DomPdf, Laravel, SabreDav, Swiftmailer, Twig, Yii, Zend Framework, and of course Symfony (we also have entries for some Symfony bundles like UserBundle, RestBundle, and JsTranslationBundle.)

[...] Today, I've decided to get one step further and to clarify my intent with this database: I don't want the database to be controlled by me or SensioLabs, I want to help people find libraries they must upgrade now. That's the reason why I've added a LICENSE for the database, which is now into the public domain.

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.

In his latest post Mathias Noback takes a look at the Symfony2 event subsystems and the answer to a common problem he's had with it in the past: circular references.

Recently I realized that some of the problems I encountered in the past could have been easily solved by what I'm about to explain in this post. [...] The problem is: having a complicated graph of service definitions and their dependencies, which causes a ServiceCircularReferenceException, saying 'Circular reference detected for service "...", path: "... -> ... -> ...".' Somewhere in the path of services that form the circle you then find the event_dispatcher service.

He shows the wrong way to solve the problem first by injecting a service container into the listener and using services directly from there. In his "entirely different and much better way" he shows a solution that removes dependencies on the main event dispatcher. He shows how to use the event subsystems to avoid this link and gives a more concrete example for domain-related events (with both code and config).

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.

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.

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.

In this new post to the PHP.cc blog, Stefan Priebsch looks at the relationship between urban legends and error handing in PHP.

Ending up in such a situation [as the tourists in the urban legend] is not the fault of the underpass: the error, made somewhere upstream, merely shows up right when approaching the underpass, and is usually difficult (or at least tedious) to handle. PHP as a programming language, just like any dynamic language, may at first appear to not need overly strict validations of data. Validation of data, however, is directly related to error handling: If data is invalid, this should be an error or an exception (if you write OOP code, which you should be doing). This error needs to be handled somewhere.

He talks about how things like field and value validation can help prevent errors further down the road. He mentions the split between application and domain logic and suggests that it's the role of the app logic to prevent bad data from making it thorough to the domain.

In software development, it is crucial that you handle any errors as soon as they occur. This requires you to actually realize that an error has occurred.

In this new post to PHPMaster.com, Alejandro Gervasio looks at working with domain objects via a transactional system using the Unit of Work design pattern.

In fact, it's feasible to wrap collections of domain objects inside a fairly flexible business transactional model and just perform several database writes/deletes in one go, therefore avoiding having to break down the process into more atomic and expensive database calls, which always lead to the session-per-operation antipattern. Moreover, this transaction-based mechanism rests on the academic formalities of a design pattern commonly known as Unit of Work (UOW), and its implementation in several popular enterprise-level packages, such as Hibernate, is quite prolific and prosperous.

He shows how to implement the "Unit of Work" design pattern via a "UnitOfWorkInterface" and a "UnitOfWork" class that implements it. The class provides methods for things like entity handling (CRUD operations) and working with the data mapper for the transactions. He also includes the code to implement the data mapper, a layer on top of a PDO-based interface that also provides CRUD operations for the data records. From this, he defines a domain model, "User", and shows how to create a new user, register it with the UnitOfWork instance and do things like update a property, delete the record and pull out the user's information.

Resting on the foundation of Polymorphism (dynamic Polymorphism, not the ad-hoc one often achieved through plain method overriding), Virtual Proxies are a simple yet solid concept which allows you to defer the construction/loading of expensive object graphs without having to modify client code.

He shows how to create a collection of domain objects that use proxies to populate their data. He includes the code for creating a "Post" interface/object as well as a Comment interface/object. These are put into a "CommentCollection" and, when it's accessed, pull the item in the collection out, only populating the data on demand.

In this previous post PHPMaster.com introduced you to the concept of "domain models", structures defining how data should be formatted for consistency. In this second part of the series, Alejandro show show to integrate them with a data access layer (DAL) to make them easier to work with.

The phrase may sound like an cheap cliché, I know, but I'm not particularly interested in reinventing the wheel each time I tackle a software problem (unless I need a nicer and faster wheel, of course). In this case, the situation does warrant some additional effort considering we'll be trying to connect a batch of mapping classes to a blog's domain model. Given the magnitude of the endeavor, the idea is to set up from scratch a basic Data Access Layer (DAL) so that domain objects can easily be persisted in a MySQL database, and in turn, retrieved on request through some generic finders.

He includes all the code you'll need to create a (namespaced) database adapter (PDO), the mapping layer to tie the domain models together and using it all in a practical "blog" example with posts, comments and users.