Matthias Noback has posted the next two parts of his "framework independent controllers" series (it started here) looking at avoiding annotations and tying up some loose ends.

From part two about annotations:

In the previous part of this series we decreased coupling of a Symfony controller to the Symfony2 framework by removing its dependency on the standard Controller class from the FrameworkBundle. Now we take a look at annotations. They were initially introduced for rapid development (no need to create/modify some configuration file, just solve the issues inline!) [...] This might not seem such a big problem at all, but the SensioFrameworkExtraBundle is a bundle, which means it only works in the context of a Symfony2 application. We don't want our controller to be coupled like this to the framework (at least, that is the point of this series!), so we need to remove the dependency.

He shows how to decouple this functionality through a proper routing configuration, fetching the needed data yourself for the request and generating the request object yourself. In part three he covers some of the comments already made about the series and how to take the final steps to abstracting out the controllers: removing bundle names from templates, removing the HttpFoundation dependency and letting go of "action methods".

Matthias Noback has a new post to his site today, the first part of a series, looking at making framework-independent controllers for use in a Symfony2 framework-based project.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

• Using the framework helper methods
• Using dependency injection (manually injecting instead)
• Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.

The Voices of the ElePHPant podcast has released their latest episode, an interview with a member of the Los Angeles PHP community, Joe Devon.

Cal's "three questions"

• What is "Global Accessibility Awareness Day" and how did it turn out?
• Tell us the good and bad parts about selecting talks for a conference.
• Tell us what you're doing as an independent developer and what advice do you have for someone wanting to go out on their own?

You can listen to this latest episode either via the in-page player, by downloading the mp3 or by subscribing to their feed.

On the Stubbles blog, Frank Kleine has pointed out a proposal from Stefan Marr to include functionality for traits in PHP.

As a language construct within PHP it would be very easy to do the same, but easier to learn and to use. Beside some keyword issues (the RFC uses "use" as keyword, but this will of course conflict with namespaces) I'm wondering what this will have an impact on reflection - the RFC stays unclear about this.

A trait is a free-floating chink of functionality that, instead of being confined to a class (or file) that has to be called on to use it, exists where the developer can use it from anywhere at any time. This helps solve some of the issues with single inheritance in PHP.

Via this post on Aaron Wormus' blog today, there's a link to an article over on The Independent.

At first my intelligence was insulted [that phpBB made the list of Best Open Source Websites], but then I saw the subtitle of the article:

Ana Kronschnabl and Tomas Rawlings pick the best open source websites where users can change the content

and then, while obviously not in the way the authors had intended it, it made perfect sense.

Some of the other sites/software (non-PHP) makes up for its inclusion in the list, including: Wikipedia, Firefox, GIMP, and SourceForge...

Via this post on Aaron Wormus' blog today, there's a link to an article over on The Independent.

At first my intelligence was insulted [that phpBB made the list of Best Open Source Websites], but then I saw the subtitle of the article:

Ana Kronschnabl and Tomas Rawlings pick the best open source websites where users can change the content

and then, while obviously not in the way the authors had intended it, it made perfect sense.

Some of the other sites/software (non-PHP) makes up for its inclusion in the list, including: Wikipedia, Firefox, GIMP, and SourceForge...