-- Jack Sleight <[EMAIL PROTECTED]> wrote (on Sunday, 10 August 2008, 09:07 PM +0100): > However, there is one more problem. As I mentioned before, I didn't want > it to be a requirement to have the ZF library path in the include_path, > however at present Zend_Controller_Action_HelperBroker relies upon it. > The helper broker currently has an addPrefix() method, which allows you > to add just a class name prefix, and no related path, but by doing that, > the broker cannot create an absolute path to the class files. This is > easily solved when adding your own paths by using addPath() instead, > however the broker adds "Zend_Controller_Action_Helper_" in by default. > There's no easy way round this at present, other than adding this into > the brokers __construct method: > > self::$_paths = array(array( > 'dir' => dirname(__FILE__) . '/Helper/', > 'prefix' => 'Zend_Controller_Action_Helper_' > ));
We've already identified the HelperBroker as being in need of refactoring to use Zend_Loader_PluginLoader. However, that class, too, relies partially on the include_path when the paths provided are not absolute paths. Have you had a chance to test any components that utilize the plugin loader? These would include Zend_Form, Zend_View (in trunk and the 1.6.0 release candidates), and Zend_Filter_Inflector. I'm curious if the PluginLoader would need to be refactored. > So, that's as far as I've got. All in all, the removal of the > require_once and loadClass calls gave me around a 15-20% speed > improvement, and more importantly, the ability to use my own class > loader makes it all the more flexible. I'd love to see this flexibility. Perhaps you could help out with some contributions? :) -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
