On 22 March 2010 14:18, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
>
> to recap regarding an earlier question i asked regarding extending
> include paths, i have an existing project (call it "proj" currently
> all under a top-level directory also named "proj") which can be SVN
> checked out anywhere under a user's home directory. so in my case, i
> might have my svn working copy under, say,
> /home/rpjday/stuff/work/proj/, and all proj-related content under
> that.
>
> at the moment, there are some subdirs under proj/ like "common" and
> "utils" and "debug", and all includes or requires throughout the
> working copy are currently and awkwardly of the form:
>
> include '../../proj/utils/somescript.php';
>
> in short, every script that needs to include another one somewhere
> else in the code structure sadly needs to know its precise relative
> location.
>
> my proposal is to get rid of most of that by:
>
> 1) having developers set a single env var PROJ_DIR in their login
> session, reflecting wherever the heck they checked out their
> working copy to, then ...
> 2) having said developers uniformly extend their directly callable PHP
> scripts with something at the very top like:
>
> set_include_path(getenv('PROJ_DIR') . PATH_SEPARATOR . get_include_path());
>
> not only will that let them simplify their command-line callable
> scripts to say just:
>
> include 'utils/somescript.php';
>
> also, as i read it, that newly-extended include path percolates down
> through all PHP scripts invoked directly or indirectly from this one,
> right? so while i could add that set_include_path() to every single
> PHP script everywhere in the code base, it's really only necessary to
> add it to those PHP scripts that people intend to *invoke* directly --
> every other script will pick it up automatically as it's called, is
> that correct? (did i phrase that meaningfully?)
>
> that was part one.
>
> the new additional complication is that some of those PHP scripts
> will manually construct HTTP POST requests and ship those requests off
> to PHP scripts that live under a public_html/ directory, whose
> scripts might *also* want to include some of those very same utils/ or
> common/ scripts but that modified include path will, of course, not
> carry across a POST request, so what's the standard way to similarly
> modify the include path of the scripts on the server end?
>
> (unsurprisingly, all those "server-side" PHP scripts are also part
> of the entire SVN checkout just so i can keep everything in the same
> place for testing.)
>
> so how can i have those "server-side" scripts extend their search
> path based on, perhaps, the same environment variable?
>
> thoughts?
>
> 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
>
>
Depending upon what is being included, an autoloader could help here.
The main payoffs for autoloading are reduced memory footprint (class
are loaded JIT) and no need for each class to know exactly where the
other classes are.
So, your main page needs to load the autoloader and the autoloader
handles the loading of the classes.
No need to change the include_path setting.
--
-----
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
