-- Mike A <mik...@hotmail.co.uk> wrote (on Friday, 19 March 2010, 04:29 PM -0000): > On 19 Mar 2010 at 10:52, Matthew Weier O'Phinney wrote: > > > -- Jake McGraw <jmcgr...@gmail.com> wrote > > (on Thursday, 18 March 2010, 07:02 PM -0400): > > > I'd like to use Zend_Loader_Autoloader::setZfPath() and the > > > autoloaderZfPath application.ini directive to select a ZF version > > > based on Environment, exactly as described here: > > > > > > http://framework.zend.com/manual/en/zend.loader.autoloader.html#zend.loader.autoloader.zf-version > > > > > > What the tutorial fails to cover is how does one introduce > > > Zend/Loader/Autoloader.php into your executing code without knowing > > > the desired ZF path/version before executing Zend_Application? It's a > > > kind of chicken and egg problem. Also, I've noticed that if you don't > > > use the same version of Zend/Loader/Autoloader.php as the one you > > > define in your setZfPath, then you'll get a fatal error (duplicate > > > class) as require_once('Zend/Loader.php') will execute because you're > > > now operating in a different directory. The only way around this issue > > > is to remove every instance of require_once from all ZF classes and > > > rely on Zend_Loader_Autoloader for all file inclusions. > > > > > > So, my question is, how are we supposed to use > > > Zend_Loader_Autoloader::setZfPath() and the autoloaderZf directives? > > > > I'd make the following recommendations: > > > > * Have a tree with just Zend/Exception.php, Zend/Loader.php, and the > > Zend/Loader/ subtree. Stick that on your include_path. This should be > > from 1.10.0 or later. > > > > * Then, in your index.php, setup autoloading and the ZF version. This > > will ensure that Zend_Application comes from the version you've > > selected, and should prevent any issues. > > > > * Optimally, on all versions of ZF, strip the require_once calls, per > > the performance appendix. > > Is this an argument for Zend shipping ZF with two installs? Part 1 the > core and part 2 the bulk? > > IMHO, philosophically and from a business perspective, it treads on > very dangerous ground for developers to move away from a framework > library by splitting out components - unless that's the shipped > method. Otherwise, what happens with version releases? Where's the > framework integrity?
Hold on a moment... The functionality described (autoloading based on ZF version) is basically functionality to support developers who are needing to develop and deploy multiple applications which each target different versions of ZF. My suggestion made above is simply to ensure you don't have conflicts between differing versions of ZF libraries on your include_path (due to needing the ZF library on your include_path in order for the functionality to work in the first place). As for splitting out components, this is actually something we plan to do for ZF2. All components would be versioned the same, but you'd be able to install a component and its dependencies anatomically. This helps answer the "use-at-will" nature of ZF much better, as it allows developers to choose the components they're using and only install those, instead of the entire framework. That said, since the framework would be versioned as a whole, if you install Zend\Filter from 2.0.1, it would install only dependencies from 2.0.1 -- framework integrity would be kept. (BTW, we'd be using Pyrus as the installer in this situation.) -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
