2009/6/1 Ralph Schindler <[email protected]> > > allow this path to be specified (or additional paths specified) in the >> .zfproject.xml file. This would also allow for project-specific providers. >> > > This is actually a chicken-egg problem. The .zfproject.xml file is not > loaded until all of the providers have been loaded, specifically the > Zend_Tool_Project providers. The overall benefit there is that > Zend_Tool_Project consumes Zend_Tool_Framework, what this ultimatley means > is that you can create your own cli/command system out of > Zend_Tool_Framework without every using Zend_Tool_Project.
Okay, that makes sense. I still think there would be value in being able to have project-specific providers without them having to live on the include path, as this would allow CLI functionality to be easily distributed with projects in the same way you can add rake tasks to Rails projects. (Perhaps application-specific providers is a better term.) E.g. the first thing I used Zend_Tool for was writing a provider for a current project to import data from the old version to new (so I can run 'zf import appname' from the command line). It's difficult for me let colleagues use this code as it either has to sit in my include path (and is thus outside of the project's source control), or I have to edit the CLI include path to point at somewhere in the project (which is messy). If we can't include additional paths in .zfproject.xml, then perhaps the include_path scanner could scan the current directory for providers if it detects that the current directory is a ZF application (i.e. if .zfproject.xml is present). That way my colleagues can just checkout the latest version of the project and will be able to run all the app-specific zf * commands immediately. -- Tim Fountain http://tfountain.co.uk/
