DevShed continues their "loaders in applications" series with this fourth part, a look at including files recursively.

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.

In this first part of a new series in application development, DevShed looks at building a loader for various resources inside your app.

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.

Debugging resources being used by your script has always been a pain, and many developers have come up with their own libraries to handle the process. Ryan Campbell has his own entry in the category - the PHP Quick Profiler.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.

Alex Netkachov has found out something interesting - the default "file" stream wrapper can be overridden.

I find today that the default "file" stream wrapper in PHP is overwritable. You only need to call stream_wrapper_unregister and then stream_wrapper_register with your wrapper.

He gives an example of a situation where you might need to "catch" certain files as they're requested and replace them with another before they make it back to the source. His example code shows how to create the stream (using stream_open) and set methods to read, write, seek and work directly with the stream resource. It takes the file requested and replaces the "5" in the name - "test.php" is included instead of "test.php5".

In a recent post to his blog Mike Lively looks at some improvements that he's worked up for the popular PHP unit testing software - PHPUnit - in regards to its filters.

I have finally gotten some time to do some long awaited work on PHPUnit. The first on my agenda was a small improvement to filtering. This was related to ticket #526. Essentially I added the ability to do both white list and black list filtering.

Besides the Include methods you can add to the data set's filtering, you can also add in Exclude filters to remove the data you don't want in the set. They can also be combined to customize your data set to your heart's content.

The TotalPHP site is recommending something that can make your development (and maintenance) life much easier in the long run - using a global configuration file through out your app.

t's one of the basics of PHP and if you read any kind of tutorial or book on the subject it's one of the first things they cover, yet I still see people no using a global 'configuration' or 'include' file. It's one of the easiest things to do and will make your life so much easier! This 'configuration' file will include anything that needs to be run on every page of the website.

They suggest that using this configuration file everywhere (including it over the entire site) can make things easier in the long run. The idea is not without problems, though. It only works until you need something custom for a certain area or page - then you have to hack it to evaluate conditions. For most simple uses, though, its a good way to share information (like database connection details) through out the application.

On the AskAboutPHP.com blog eldee takes a look at helpers, plugins and libraries in the CodeIgniter PHP framework including some examples.

With so many published PHP classes and functions, it would be a shame if we couldn't use them in CI. Fortunately CI (like all good frameworks) provides not one but three ways to integrate 3rd code, by using Helpers, Plugins and Libraries. [...] As I found out during the course of my CI project, Helpers, Plugins and Libraries are nothing more than glorified includes. I can pretty much take any 3rd party code and integrate into my application using any of the 3 methods.

His example uses the Google Graph class as each type (helper, library and plugin) with some example code.

In a new entry Knut Urdalen looks at something that some PHP developers might have forgotten about - the return value of the include statement.

PHP never stops surprising me. I just found out that you're able to return values from the inclusion statements (require, require_once, include and include_once) through an example of Zend_Config.

His example puts an array of values inside the include file with a return statement. This script is included from another and, because of the return, the array data is passed back out into a waiting variable set equal to the include statement.

On the TechFounder blog, Eran Galperin has taken a look at object-oriented templating in PHP applications, comparing the older search and replace method with the inclusion of PHP-based templates.

PHP as a language can be considered a templating system, as in its root it was meant to modify HTML pages dynamically. The need for more structured templating systems arose as PHP applications have grown more and more complex, giving birth to much more specialized and focused solutions.

He illustrates with an object replacement example - parsing the template as a PHP script and replacing any objects found with the corresponding object property value.

Bradley Holt has pointed out the portion of the roadmap for the Google App Engine that includes PHP:

According to the newly posted App Engine Product Roadmap, there are plans to add "support for a new runtime language." [...] Looking at the issue list, support for Java is the most requested item followed by support for PHP, Ruby, then Perl.

Be sure to show your support for the inclusion of PHP into the system by hitting a star rating on this page.