It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. [...] Our first idea is obvious: symfony2 uses by default a parameters.yml file, which gets imported by your configuration (config.yml) [...] So nothing new here and this setup works perfectly, provided that your symfony2 project is the ONLY thing that needs to be configured. As soon as you add multiple other components (like gearman or activemq workers that need to connect to solr too), they need to share this configuration.

His solution involves falling back to the INI-file format that's known as useful for several different languages and tools. Because of how Symfony2 reads these files though (only looking for "parameters") he's had to create a "ConfFileLoader" instance of the "FileLoader" that uses the parse_ini_file method to parse the data and return it back to the main container as parameters. He also includes the code/config you'll need to implement this custom loader into your application.

Doctrine's DataFixtures are a great way to add test data to your application. It's fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn't a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

With CakePHP 2.0, they have dropped support for PHP 4 and have refactored the library code to make it strictly complaint with PHP 5.2+. Modeled on Ruby on Rails (RoR), CakePHP is a tough competition to Zend framework, Symfony and CodeIgniter.

Besides the topics mentioned above, he also goes into the details of the new CakeRequest and CakeResponse models (to access information about teh current request/response). Summaries of all of the new functionality are provided along with some sample code where needed to illustrate.

This opens so many doors to developers, because, finally, we can bundle repeated functionality inside a package and distribute it as open-source or free code. Even if you don't want to expose your own packages, you can re-use them internally, which makes for a veritable mix of both writing application specific code, and abstracting elements of those applications out (such as an authentication engine, for instance) to become re-usable and unspecific.

He uses the post to give more specifics (that are currently missing from the manual) on what these packages are, how to use them via the framework's loader to both add and remove. Then, classes inside the package can be loaded just like any other CodeIgniter resource.

To avoid an eventual (and unnecessary) instantiation of the loader class, it would be helpful to declare the mentioned "load()" method static. Thus, bearing in mind this important concept, in this fifth part of the series I'm going to enhance the signature of the "Loader" class created previously by turning its loading method into a static one.

They change the definition of the function to be "public static" making it callable both through the "self" keyword and outside the class with the "::" operator.

While this file loading class in its current incarnation does a pretty good job, it lacks an important feature that could be added with relative ease. It cannot perform a recursive search through the web server's file system, and afterward include a specified file within a given application.

This article updates their class with a new feature to let the script looking for files recursively in a directory.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.

As its name suggests, a file loading program (or a resource loading program, to express the concept more accurately), is simply a PHP module that takes care of including, usually via its set of "include()/require() native functions, files that are required by an application to make it work as expected. [...] It's worthwhile to mention, however, that it was necessary to create an instance of the aforementioned class to load a determined file. This is a process that can be completely avoided in terms of good coding habits. But how can this be achieved? Well, it's feasible to statically call the class's load()" method, preventing its unwanted instantiation.

The code examples of the simple loader class (a require_once wrapped in a try/catch) and a usage example.

Loading sources on the fly is one of the most common tasks that PHP programmers have to tackle during the development of web applications. This typical situation must be faced independently of the scale of the programs being created. This means a loader mechanism must be developed.

Their basic loader class uses a call to a load() method to do two things - check to ensure that a file exists and, if it does, include it (technically a require_once). They also put a bit of exception handling around it to help catch any errors thrown on the include.

On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?

He uses a set of scripts he developed to compare the bytecode caches of the requests both with and without the caching turned on. He ran the tests on a PHP 5.2 and PHP 5.3 installs with the lower (better) numbers coming from the latter in requests per second. He highly recommends turning this caching on on your system if you haven't already.