On 23 March 2010 13:11, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > On Mon, 22 Mar 2010, Nilesh Govindarajan wrote: > >> What I do is, set the include path in the top-level bootstrapper. >> >> /bootstrap.php: >> >> set_include_path(dirname(__FILE__) . '/lib' . PATH_SEPARATOR . >> get_include_path()); >> >> Then I load the autoloader from /lib/autoload.php at the time of bootstrap. >> >> /lib contains others /lib/Common, /lib/Util, etc. >> >> So when I say "new Common_Form();", it will include /lib/Common/Form.php > > not bad, i'll look at that more closely. but let me mention a > wrinkle i mentioned before and expand on it so folks can see what i'm > trying to do and why i was suggesting the strategy i did. > > as i said, something i've used before (in admittedly non-PHP > projects) was to require developers who checked out the code base to > set a single env variable (say, PROJ_DIR) to point at the location of > the checkout. while someone earlier suggested that was "overkill," > this approach had a major benefit for me. > > in both that earlier project and in this current PHP project, there > was the possibility of multiple code base checkouts -- perhaps the > current stable one and a newer development one. i'm a big fan of lots > and lots of automated testing so i would write numerous scripts that > would, from the command line, test the code base. > > i want those test scripts to work equally well on the production > checkout and the development checkout, and i also don't want to be > forced to locate those test scripts in any particular directory. i > might want a totally separate checkout for test scripts, and the > freedom to check them out wherever i want. > > quite simply, i want to be able to check out my test scripts, and > tell them *which* code base to run against. and i see no way around > that other than to have to explicitly identify the location of the > code base to be tested, and that's what the PROJ_DIR variable was for. > using that single variable, i could reset and point at whatever > checkout i wanted to test. and i didn't see any easier way to do it. > > i've seen lots of suggestions of very clever ways to have the > components of a single checkout know there the rest of the checkout > is, and most of them would work fine. but it seems clear that none of > those techniques would give me the ability to do what i want above -- > to arbitrarily refer to checkouts from *elsewhere* and have everything > still work. and there's one more thing. > > to speed up coding, i've added a "utils" directory to the code base, > containing (you guessed it) handy-dandy little utilities. and since > they're part of the repository, it's not hard for other parts of the > checkout to include them. but, eventually, someone is going to start > a second, sort-of-related project, and will want to reuse some of > those utilities, and the obvious solution will be to move those > utilities out of the first project and give them their own checkout > (svn external?), and again, i don't want to lock any scripts into any > particular location. > > the single environment variable idea still seems like the obvious > solution, or maybe even more than one. because i don't see that > there's any way to make this *completely* automated. at some point, > if i want as much flexibility as possible, a developer who checks out > one or more of these projects has to identify what directories he > wants to work with, and all subsequent includes will work off of that. > > thoughts? sorry for rambling on so long. > > rday > -- > > ======================================================================== > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > ======================================================================== > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > However you want to identify the location, the autoloading techniques will allow you to only need to identify the location once. As compared to every file meticulously maintaining relative links to files. So, for testing, would this not work? RunTests C:\Dev\Checkouts\PROJ\trunk\tests RunTests C:\Installed\PROJ\V1.1\Tests RunTests C:\Installed\PROJ\V2.2\Tests RunTests C:\Installed\PROJ\V3.3\Tests sort of thing? And in RunTests, you set the location based upon the $argv[1] (using the autoloader technique). No env_var. No include_path. -- ----- Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
