So here is what I ended up doing: Directory for different versions of ZF %> mkdir -p /usr/share/php/ZendFramework
Directory for Zend_Loader_*, Zend_Application, Zend_Exception (static version 1.10.2) %> mkdir -p /usr/share/php/ZendFrameworkLoader/library/Zend %> cd /usr/share/php/ZendFramework %> wget http://framework.zend.com/releases/ZendFramework-1.10.2/ZendFramework-1.10.2-minimal.tar.gz %> tar -xzvf ZendFramework-1.10.2-minimal.tar.gz %> mv ZendFramework-1.10.2-minimal 1.10.2 %> cd 1.10.2/library/Zend Copy out Application, Loader classes before removing require_once %> cp -r Exception.php Application.php Loader* /usr/share/php/ZendFrameworkLoader/library/Zend Remove require_once calls from ALL versioned copies of ZF %> find . -name '*.php' -print0 | xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g' Now in my index.php: http://gist.github.com/338279 Some takeaways: 1. Won't be able to use pear to keep up to date on ZF, though I knew this going in. 2. Still can't get application.ini directives to work, though I don't think I'd want to use application.ini to define my autoloaderZfPath because then I'd have to segregate a whole bunch of ZF classes. 3. Using this method, the following application.ini directives broke for me, so I had to replicate the functionality outside of Zend_Application, in my index.php: includePaths.library autoloadernamespaces.My = "My_" This may be because I'm now replacing the autoloader initialized by Zend_Application with my own. 4. The section for setZfPath needs to be rewritten to reflect the fact that you'll need a modified ZF install (without require_once) in order to use it. Those issues aside, we're loving the ability to dynamically assign different ZF versions by environment. Thanks for all the help! - Jake On Fri, Mar 19, 2010 at 2:20 PM, Mike A <[email protected]> wrote: > On 19 Mar 2010 at 13:22, Matthew Weier O'Phinney wrote: >> -- Mike A <[email protected]> wrote >> (on Friday, 19 March 2010, 04:29 PM -0000): >> > On 19 Mar 2010 at 10:52, Matthew Weier O'Phinney wrote: >> > >> > > -- Jake McGraw <[email protected]> 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. >
