Richard McIntyre has a new post to his blog showing how he set up OAuth support in a Lithium-based application with the help of a handy plugin (li3_oath).

The OAuth protocol is a fantastic way to login to remote services and websites. Unfortunately the spec is different in OAuth 1.0 and the yet un-solidified 2.0, the implementation is also different across different services. At the moment this is a bit of a goose chase, but libraries like li3_oauth can help! [...] I like to be in control and calling the shots! I also want to have users have the option to login to other services under the same umbrella. Working directly with OAuth is what I wanted to do. Of course I was doing this in Lithium because it is clearly the best PHP Framework!

His process is broken up into four steps:

• Grab the latest version of the li3_oauth plugin
• Fork and refactor the plugin
• Create the Tweet and Facebook controllers
• Refactor a bit more to turn it into a service

The code changes are pretty minimal and are included in the post.

Richard Miller has a new post to his blog today that recommends moving away from the base controller the Symfony introductory documentation has you make. He suggests an alternative that can be used more widely.

In fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them. I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller.

He starts with his "TestimonialController" that does some of the basic CRUD operations on the testimonial information. He shows you, step-by-step, the refactoring needed to stop using things like the default controller helpers (each with replacement code). With those removed, he can move to extend "ContainerAware" instead of "Controller", make the controller a service and doing some dependency injection for needed resources.

James Morris has a new post to his blog talking about a way he's found to remove dependencies from parts of your code by using the Observer pattern (specifically with the SplObserver and SplSubject components of PHP's SPL libraries).

Working on a symfony app, you usually have a mix of domain objects that are used by symfony actions, interspersed with symfony specific code such as logging and sfContext type stuff. A common bad practice I see is symfony specific code peppered inside of domain objects that could be used elsewhere (such as inside of a Zend app or a script from the cli) but now can't as they're coupled to the symfony code. One way you can remove an unwanted dependency is to use the Observer pattern - the dependency is pushed from inside the subject object to the client code that initialises the subject.

He sets up a scenario where a symfony action hits a web service and there's a dependency on two other types of objects (a service and transport object). He starts with the code for this method and gradually refactors out those two dependencies, removing an sfContext call from inside the service client and adds attach/detach/notify methods to implement the SplObserver on the class.

New on his blog today Lars Strojny has posted the first part of his look at dependency injection and how he's been using it to do some refactoring in his applications. He uses the Symfony DI container in his examples, but really you can apply the principles to just about any of the other current DI offerings.

Working heavily with the Symfony2 Dependency Injection Container, I feel that we found some typical refactorings towards a DI container that emerge during the introduction of such a component. I want to write down the preliminary results of trying to systematize more or less as a draft. I will use the Symfony2 DI container configuration as an example but most of the refactorings should be applicable to other containers as well, some of them even to dependency injection without a container.

He's broken it up into a few different sections:

• Making a dependency explicit
• Introducing interface injection
• Exposing the service

Richard McIntyre has posted about his experiences in working the features the Lithium framework into one of his current applications, mostly because of its support for Doctrine and its heavily decoupled nature.

I have a legacy application which was originally written in straight PHP with a few classes that I have created for convenience, but this is old and I am wanting to get this into a modern web framework. [...] I wanted to update my site with better validations anyway so I will start with flash messages and then validations. For flash messages in lithium you will need the li3_flash_message plugin.

He works through the different parts of the framework setup he needed including a simple bootstrap file and configuring it to use the li_flash_message library. He shows how to use validation rules on submitted data to ensure things like email an link format validity as well as spit back a message for any that are incorrect.

Jani Hartikainen has a suggestion for all developers out there who are working through their code and refactoring as they go - make unit tests a requirement during the process.

What should you do to make sure new code works properly when you're refactoring old code? I asked myself this question recently, when I needed to refactor a big bunch of procedural PHP code into a neat, testable, OOP-style interface. The conclusion I came into is that you should write unit tests - not to test the old code, but as requirements for the new code.

He suggests setting up a system where unit tests are set up to be where the requests are recorded - a sort of reverse TDD since you already have code to work with. Even if all of the tests aren't 100% implemented, at least you can run them and see what features you have left to do.

Wouter Lagerweij has posted a list of books he thinks every programmer should read to help them get a better handle on their process overall (they apply to any language out there, really).

When discussing books on software engineering with colleagues, I got the idea of listing the best books I've read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read.

He lists five books that cover some of the "meta" about programming:

• Applying UML patterns
• Design Patterns - GoF
• Refactoring (Martin Fowler)
• Test-Driven Development (Kent Beck)
• Clean Code (Robert Martin)

In a new post to his blog Sebastian Bergmann talks about some updates to PHPUnit that are coming in the 3.5 release.

When you look at the list of changes for PHPUnit 3.5, you will see that many of them deal with refactoring to components. Here is an overview of these new components.

Components that were refactored to work even better include:

• PHP_CodeCoverage
• DbUnit
• PHPUnit_Selenium
• PUPUnit_MockObject

On PHPBuilder.con today there's a new post from Jason Gilmore looking at using procedures and views in MySQL to refactor and simplify your site.

One particularly prominent mistake many programmers make is heavily intermingling the application logic and the domain model. PHP developers, for example, have a tendency to jam a tremendous amount of SQL into their website logic, resulting in undecipherable, unmaintainable code. [...] MySQL stored procedures and views can not only go a long way towards separating the logic and domain model, but they also can easily be integrated into PHP.

He includes several examples of how to create simple views in your database with tables from a possible e-commerce application holding order information and customer details.

In a (sort of) response to some of the refactoring posts that Brandon Savage has been posting, Dagfinn Reiersol has suggested something that should have been done from the start - write unit tests before you refactor.

That said, I do have something important to add. The series is missing the first, most basic rule: Don't refactor unless you have good automated test coverage (typically with unit tests). And if there are no test, write them before you start refactoring.

He notes that with successful unit tests in place, you can freely change the underlying structure of the application with (almost) no worries that your application will fall apart the next time it's run. He does point out the need for a bit of refactoring before the tests could really be successfully run (since there's a need for an external twitter connection).