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
