On 19 Mar 2010 at 13:22, Matthew Weier O'Phinney wrote: > -- 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.)
Thanks once again Matthew. As for the autoloading based on ZF version I wholeheartedly understand that whilst a developer would wish to "muck around", a release version should avoid it. That is not what the manual implies though - it refers to "fixing" a version in context with the mucking around bit. For the vendor to come out and mention splitting out components (I presume you mean components families) as part of the philosophy is wonderful news. Such managed philosophy is streaks ahead of the porridge-cum-spaghetti found in other products like those beginning with C or D - that's not to decry either porridge or spaghetti as foods ;) Does the step towards Pyrus (http://pear.php.net/manual/en/pyrus.php) suggest a wholesale use of an XML config file with which non-Zend products (modules) can be registered and plugged? If so, are there any references/blog posts on the subject and what's going to happen? They would be useful. Cheers... Mike A.
