Re: [Fwd: Re: PEAR framework changes for PHP5]

Lukas Smith wrote:

hmm I dont understand the issue .. just add the paths to your include_path using ini_set or even set_include_path

The issues is that current PEAR classes have expectations about where to find files. It would be nice if you could specify not only the name of a custom class, but the location (yes, relative to somewhere on the include path) of the file that contains that class. For example, if I have a web application that lives in /var/www/apps/mywebapp I might have some custom db drivers located at /var/www/apps/mywebapp/classes/mywebapp/db/MysqlCachingDriver.php /var/www/apps/mywebapp/classes/mywebapp/db/PgsqlCachingDriver.php Now, I want users to choose which driver to use in a configuration file. I want to provide the option of having them choose their own drivers also. So, in the config file, I want to be able to specify a path: <db> <driver>mywebapp/db/MySQLCachingDriver.php</driver> <dsn>mysql://root@localhost/webappdb</dsn> </db> [or] <db> <driver>someotherapp/db/MyDriver.php</driver> ... </db> Ideally I wouldn't need to write a wrapper that would include the file & then call MDB. I would just pass that value directly to MDB & it would know what to do with it. Now, that is ideal -- and the solution that Jon mentioned about just including it before calling the factory is also doable. Maybe others haven't had to deal with this problem in PHP. I certainly have had a number of projects where I've needed to reference classes in a way that included path information. For example, in Phing you can register your own task (or type, selector, filter, mapper) classes: <taskdef name="my-task" classname="mywebapp.phing.MyTask" /> As I mentioned before this is one of those cases where dot-paths are used. Not ideal, but at least platform independent & not much overhead to transform it to mywebapp/phing/MyTask.php (or mywebapp\phing\MyTask.php). Hans