setting global include paths

[konky2000]

I was looking at phpmvc.net and noticed that they do the following:

     function getGlobalPaths() {
 
         // Setup the main phpmvc application include() directories here
         // Note: could be placed in a n xml config file later !!
         $appDirs = array();
         $appDirs[] = ''; // application root directory
         $appDirs[] = 'WEB-INF';
         $appDirs[] = 'WEB-INF/lib/collections';
         $appDirs[] = 'WEB-INF/lib/database';
         // ... there are about a dozen lines like this
         $appDirs[] = 'WEB-INF/classes/phpmvc/upload';
         $appDirs[] = 'WEB-INF/classes/phpmvc/utils';
         return $appDirs;
 
     } 

They have a couple of other methods that create further directory names which are all added together into a long list of directory names called $cPath that are then fed to the following:

 ini_set('include_path', $cPath); 

The result is that 'include_path' has a couple dozen paths in it, and any time a file is included one only needs to refer to the filename in any include like:

 include 'PressRelase.php'; 

My initial gut feeling is that this is a bad idea. It seems like a potential performance problem if every single time I include a file, PHP is going to have to search through all those directories until it find the file I'm looking for.

What I do is set constants like TEMPLATES, CLASSES and then when I need to include a TEMPLATES, I go

 include TEMPLATES.'PressRelease.php'; 

Are things like php.mvc's setup common? Is it a performance hit to fill 'include_files' with so many paths?

[sid egg]

....

 ini_set('include_path', $cPath); 

The result is that 'include_path' has a couple dozen paths in it, and any time a file is included one only needs to refer to the filename in any include like:

 include 'PressRelase.php'; 

My initial gut feeling is that this is a bad idea. It seems like a potential performance problem if every single time I include a file, PHP is going to have to search through all those directories until it find the file I'm looking for.

What I do is set constants like TEMPLATES, CLASSES and then when I need to include a TEMPLATES, I go

 include TEMPLATES.'PressRelease.php'; 

Are things like php.mvc's setup common? Is it a performance hit to fill 'include_files' with so many paths?

It's definately slow to use include_path, however, I do this, I find it works best on a cPanel server that you have reseller/whm on. I have 2 servers, one is shared [and i have a reseller], one is dedicated

On the reseller one, I have an account called global, and, I include all my stuff through it. include("/home/global/class/asdf.php");

On the dedicated one, I do the same thing, but use /usr/phpdev/classes/

However! Neither of these are transferable solutions, if you plan on distributing your projects I find the define() method works the best (your include TEMPLATES."/file";

My initial gut feeling is that this is a bad idea. It seems like a potential performance problem if every single time I include a file, PHP is going to have to search through all those directories until it find the file I'm looking for.

It also really hurts your global namespace for files :-)

[Kilroy]

I use an object with public variables, which get assigned from a config.php file. Using them goes as follows:

require_once $config->site_path . '/lib/class_blah.php'; 

This config object can then be passed on to other object, which gets rid of the use of globals. I also did not like the idea of making constants of all these variables, but it might be faster. I'll look into it sometime.

[Tanus]

We use something similar in prado (using('path.to.class.folder') which adds the path/to/class/folder directory to the include path, which is then hit by __autoload. This way only folders that are actually going to be used are added to the classpath instead of having to have it predefined somewhere. There is something of a performance hit, but the ease of just having your classpath instead of worrying about including() files is better.