On NetTuts.com there's a new screencast posted showing you a good way to create a better workflow in your PHP development using Composer and PHPUnit.

In this video tutorial, we'll again focus on workflow. Specifically, we'll use Composer's built-in autoloading capabilities, along with namespacing, to make for an elegant testing experience. We'll also review a handful of PHPUnit best practices, as we get setup with these tools.

He shows you how to use Composer to load in the packages from other projects (as well as your own) and using PHPUnit to execute unit tests for your application. He uses test-driven development, but it's not a required part of the workflow. He helps you create a simple "Calculator" test. He also shows how to manually modify the Composer classmap to load in your own classes.

Juan Treminio has a new post to his site today talking about Composer and namespacing and shows you how the two work together to make using 3rd party tools easy.

You've heard of Composer, right? The nifty new tool for PHP that aims to centralize and streamline package management? Do you also know of, but don't really understand how namespaces work in PHP? Then let's set you straight! In 5 minutes you'll learn how Composer's autoloader and namespaces work!

He's broken it up into a few sections:

• Getting Composer up and running
• Making a basic "composer.json" file
• Going through what the "install" creates (including the "autoload_namespaces.php" file)
• Using the vendor/ autoloader

As a bonus, he also shows how to implement your own namespacing in the "composer.json" file if you have a special case - just use the "autoload" section in the configuration (examples included).

On NetTuts.com today there's a new tutorial introducing you to namespaces in PHP and a complete guide to the features that come with them.

It's been a bumpy ride, in regards to namespace support in PHP. Thankfully, it was added to the language in PHP 5.3, and the applicable structure of PHP code has improved greatly since then. But how exactly do we use them?

They start with a definition of a namespace (for those unfamiliar with the term) and get right into the code showing their use in PHP:

• Defining a Namespace (and Sub-namespaces)
• Calling Code from a Namespace (using Unqualified/Qualified/Fully Qualified names)
• Dynamic calls
• The namespace Keyword
• Aliasing or Importing

Michael Nitschinger has a new post focusing on one of the more commonly used, but maybe just as commonly misunderstood, part of PHP - exceptions and their handling. His latest post looks at what Exceptions in PHP have to offer and provides some "best practices" in their use.

Exceptions are and should be an integral part of any general purpose programming language. PHP introduced them long ago (with the release of PHP 5 or 5.1), but it still seems that many of the concepts are not fully understood or ignored by the community. This post aims to be a solid introduction to exception architecture, handling and testing. At the end of the post you should be able to know when to raise an exception and how it should look like.

He talks about situations when (and when not) to use exceptions, normalizing them for easier try/catch-ing and includes the exception class hierarchy, including the types pulled from the SPL. He shows examples (based on the Lithium framework's namespacing) how to create "namespaced exceptions" and how to use these in a bit of sample code. He also mentions the use of the custom error handling with the ErrorException as well as a quick look at testing these basic and custom exceptions correctly (PHPUnit-based tests).

Stefan Koopmanschap has a quick new post to his blog with a handy tip for Composer and Cilex/Silex users when dealing with custom namespaces.

For a new proof of concept application I'm building, I need both a simple web interface as well as some commandline tools. I decided to use Silex for the web interface and Cilex for the CLI tools, and opted for using Composer for installing these dependencies into my project. I ran into some issues with the custom project libraries I was building for this application however. Registering my custom namespace into Silex and Cilex didn't result in the classes being loaded for some reason. Composer helped me out though.

His solution involves letting Composer be the default autoloader for the application via an "autoloader" configuration option in the "composer.json" (that can also take a classmap option if you're not PSR-0 compliant, see here).

For those that either haven't worked much with PHP 5.3 in their applications (or just haven't gotten around to using the feature) Rob Allen has put together an introduction to namespaces to guide you through some first steps and share some example usage.

I know that there are a lot of posts now about namespaces in PHP 5.3. This is mine which is how I learnt how they work. [...] That is, namespaces allow us to: combine libraries with the same classnames, avoid very long classnames and organise our code easily. Note that namespaces do not just affect classes. They also affect functions and constants.

He starts with the basic namespace definition (using the "namespace" keyword), shows how to import another namespace with "use" and the use of the __NAMESPACE__ constant to determine what namespace you're operating in. More information on namespaces can be found in the PHP manual.

On PHPMaster.com today there's a new tutorial introducing you to the PSR-0 standard and how it effects the autoloading in many PHP applications and frameworks. Specifically, they show how it's implemented in a Symfony2 component

In this article I'll walk you through the "history of autoloading," from the older to the current PSR-0 standard autoloader approach found in many PHP frameworks such as Lithium, Symfony, Zend, etc. Then I will introduce you to the ClassLoader component from the Symfony2 project for PHP 5.3 which follows the PSR-0 standard.

He starts with a look at a basic "__autoload" function call that looks in a directory for libraries. Improving on that, he makes two methods for loading - one for controllers, the other for models - and a loader that splits on the "_" character and determines the path from there.

Even this isn't PSR-0, though, so he shows how using namespace information, you can load classes in a unified way. He shows how to implement this with a loader that's already well-developed and ready for use - the Symfony ClassLoader component. They show how to register namespaces, prefixes as well as use the APC functionality to manually store/fetch the APC version of the loaded file's opcodes.

Larry Garfield has posted the results of some of his research into popular PHP frameworks and projects and see how they handle their structure as it relates to the PSR-0 standard.

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

The projects he looked to for his examples were:

• CakePHP
• Symfony2
• Silex
• CodeIgniter
• Zend Framework 2
• Composer

Fabien Potencier has posted the seventh part of his series looking at how to make a custom framework on top of the components from the Symfony2 framework. In this part of the series he improves his basic framework by adding some namespacing to organize the application a bit more.

If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request. As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

He puts the main front controller in just the "Simplex" namespace but adds in others for the controllers and models. He also updates his Composer configuration to create some PSR-0 autoloading.

Chris Hartjes has a reminder posted to his blog today in the form of this recent post that "scope is not a mouthwash" - personal experience from his recent development where he forgot about something as simple as scoping (and it caused him all sorts of headaches).

For [a chapter in my book on dependency injection] I am using Pimple, an incredibly small but effective dependency injection container. Easy to use, simple and effective documentation, just what I was looking for. I also noticed that Pimple supported the use of closures (or anonymous functions) as a way of storing a dependency. Then things got stupid.

He shares a bit of code showing how he added it to his bootstrap but was given a "cannot find class" error when he tried to use the tool. He walks through the steps he followed to track down the problem - looking closer at Pimple, investigating closures and, the ultimate problem, namespace scoping. He was missing a "" to start his namespace and closures work slightly differently:

So why does it behave differently inside closures? I am not 100% sure, but if I had to make an educated guess I would say that when trying to resolve namespaces inside a closure, the interpretor doesn't assume that it is already inside the global namespace, that it is in a namespace of it's own.