another question on setting include paths for a project

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

Re: another question on setting include paths for a project

On 22 March 2010 14:18, Robert P. J. Day 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
> --
>
> ==================== =====
==================== =====3D=
==================== ===3D
> Robert P. J. Day                 =
              Waterloo, Ontario, CANADA
>
>            Linux Consulting, Training and K=
ernel Pedantry.
>
> Web page:                   =
                    =C2=
=A0  http://crashcourse.ca
> Twitter:                   =
                    http:=
//twitter.com/rpjday
> ==================== =====
==================== =====3D=
==================== ===3D
>
> --
> 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.



--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: another question on setting include paths for a project

On Mon, 22 Mar 2010, Richard Quadling wrote:

> 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.

ok, i'm looking at the PHP manual page for autoload, sample:

function __autoload($class_name)
{
require_once $class_name . '.php';
}

and some obvious questions suggest themselves:

1) in as simple an example as above, does the include_path still
control the search? since i'm not doing anything fancy above in terms
of specifying *where* that class is defined, it seems that i'll still
have the same problem to solve, no?

2) i'm guessing that i can make the __autoload function as
sophisticated as i want, in that i can have it consult an environment
variable to determine where to search, but i'm still unsure as to how
i can set an environment variable to be consulted on the "server"
side.

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

Re: another question on setting include paths for a project

On 03/22/2010 07:48 PM, Robert P. J. Day 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
> ============================================================ ============
>

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

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: another question on setting include paths for a project

On Mon, Mar 22, 2010 at 10:51:38AM -0400, Robert P. J. Day wrote:

> On Mon, 22 Mar 2010, Richard Quadling wrote:
>
> > 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.
>
> ok, i'm looking at the PHP manual page for autoload, sample:
>
> function __autoload($class_name)
> {
> require_once $class_name . '.php';
> }
>
> and some obvious questions suggest themselves:
>
> 1) in as simple an example as above, does the include_path still
> control the search? since i'm not doing anything fancy above in terms
> of specifying *where* that class is defined, it seems that i'll still
> have the same problem to solve, no?

Yep and yep.

>
> 2) i'm guessing that i can make the __autoload function as
> sophisticated as i want, in that i can have it consult an environment
> variable to determine where to search, but i'm still unsure as to how
> i can set an environment variable to be consulted on the "server"
> side.
>

That's the key. You can do anything you want inside __autoload(). If you
must consult something in the environment, there are a couple of ways to
do it. First, set a variable in the $_SESSION array, and consult it in
__autoload(). Second, use a configuration file for your application.
Have it in a stable place, and read the values out of it as needed.
Consult these in your __autoload() if you like.

Paul

--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: another question on setting include paths for a project

On 3/22/10 10:25 AM, Paul M Foster wrote:

> That's the key. You can do anything you want inside __autoload(). If you
> must consult something in the environment, there are a couple of ways to
> do it. First, set a variable in the $_SESSION array, and consult it in
> __autoload(). Second, use a configuration file for your application.
> Have it in a stable place, and read the values out of it as needed.
> Consult these in your __autoload() if you like.
>
> Paul

I'd suggest skipping __autoload() and going straight for
spl_autoload_register(), as it does the same thing but is more flexible
since you can then have multiple autoload callbacks if necessary.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: another question on setting include paths for a project

On 22 March 2010 15:28, larry@garfieldtech.com wrote:
> On 3/22/10 10:25 AM, Paul M Foster wrote:
>
>> That's the key. You can do anything you want inside __autoload(). If you
>> must consult something in the environment, there are a couple of ways to
>> do it. First, set a variable in the $_SESSION array, and consult it in
>> __autoload(). Second, use a configuration file for your application.
>> Have it in a stable place, and read the values out of it as needed.
>> Consult these in your __autoload() if you like.
>>
>> Paul
>
> I'd suggest skipping __autoload() and going straight for
> spl_autoload_register(), as it does the same thing but is more flexible
> since you can then have multiple autoload callbacks if necessary.
>
> --Larry Garfield
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Completely agree with Larry here. spl_autoload_register is __autoload++.

Essentially, the autoloader knows where it is and should know where
everything else it is expected to load is.

Having a naming convention that say maps class name to file path/name
(Zend_Soap_Wsdl_Exception maps to ./Zend/Soap/Wsdl/Exception.php) and
sticking with it allows for a single autoloader to be used for any
root name.

Autoloading only really works out-the-box with classes. There has been
discussion on making this work with functions and namespaces.



--
-----
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

Re: another question on setting include paths for a project

On 22 March 2010 14:51, Robert P. J. Day wrote:
> On Mon, 22 Mar 2010, Richard Quadling wrote:
>
>> 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.
>
>  ok, i'm looking at the PHP manual page for autoload, sample:
>
>  function __autoload($class_name)
>  {
>    require_once $class_name . '.php';
>  }
>
> and some obvious questions suggest themselves:
>
> 1) in as simple an example as above, does the include_path still
> control the search?  since i'm not doing anything fancy above in ter=
ms
> of specifying *where* that class is defined, it seems that i'll still
> have the same problem to solve, no?

No. The autoloader is part of the project, so it will know its
relative pathing to the other files. __DIR__ in the autoloader will
tell the autoloader where it is and all associated files should be
relative this.

You only need to know the relative path of the autoloader.

No need to alter include_path and you can remove all those
(require|include)(_once)? lines too as the autoloader kicks in
whenever a class it requested that hasn't been loaded.

>
> 2) i'm guessing that i can make the __autoload function as
> sophisticated as i want, in that i can have it consult an environment
> variable to determine where to search, but i'm still unsure as to how
> i can set an environment variable to be consulted on the "server"
> side.

I think once you've got the autoloader working, you don't need to worry.

> rday
> --
>
> ==================== =====
==================== =====3D=
==================== ===3D
> Robert P. J. Day                 =
              Waterloo, Ontario, CANADA
>
>            Linux Consulting, Training and K=
ernel Pedantry.
>
> Web page:                   =
                    =C2=
=A0  http://crashcourse.ca
> Twitter:                   =
                    http:=
//twitter.com/rpjday
> ==================== =====
==================== =====3D=
==================== ===3D
>



--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Fwd: Re: another question on setting include paths for a project

oops, mailed the OP direct rather than the list. sorry.

-------- Originele bericht --------
Onderwerp: Re: [PHP] another question on setting include paths for a project
Datum: Mon, 22 Mar 2010 15:58:28 +0000
Van: Jochem Maas
Aan: Robert P. J. Day

Op 3/22/10 2:18 PM, Robert P. J. Day schreef:
>
> 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?

I think the whole 'set an ENV var in their shell session' idea is overkill.
everything is checked out from svn, the structure of the project is known,
there is no reason not to use relative paths for the includes, there is
no need to tell the scripts where stuff is in this scenario - they can
work it out automatically.

the following might give you an idea for a bit of bootstrap code that's included
by everything:

define('INC_DIR', dirname(__FILE__));

this would allow all other code to use absolute paths and allow you to set
the include_path to ''.

how do the cmdline scripts know which URL to hit ... I would assume that this
URL can change depending on whose checkout it is and the context (dev/prod),
that means there is already a config file or some such - possibly a good place
to stick the include path or define the include dir.

.... and now for something 'completey' different:

another trick I've used is to use custom ini settings in conjunction with
get_cfg_var() - each developer/installation would have their own custom ini
file (which you can store in svn too) .. the ini file would be symlinked to
from the dir php is setup to read additional ini files from, the contents of
the ini file would be something like:

[My Cool App]
my_cool_app.public_url = 'http://local.coolapp/';
my_cool_app.inc_dir = '/path/to/cool/app/';

you can then grab these values from anywhere using get_cfg_var('my_cool_app.inc_dir'),
often I find that additional config stuff is needed per installation - mostly related
to webserver setup (which sometimes differs somewhat between live and dev installs -
SSL may not be available/required/wanted and if it is IP addresses need to be hard coded,
apache may require you to use absolute paths, test systems may require IP restrictions, etc)

so I setup a dir structure like so:

/cnf/targets/localhost.jochem/php
/cnf/targets/localhost.jochem/httpd
/cnf/targets/localhost.charlie/php
/cnf/targets/localhost.charlie/httpd
/cnf/targets/some.test.domain/php
/cnf/targets/some.test.domain/httpd

I'd also maintain an example dir specifying minimum requirements for each install's configs:

/cnf/targets/example/README
/cnf/targets/example/php/mycoolapp.ini
/cnf/targets/example/httpd/public.mycoolapp.conf

if there is a need to have php code look into the current installs cnf dir I'd
put a file called 'target' in /cnf/ with the contents set to the
install dir in question (e.g. 'localhost.jochem') ... this file would be excluded
from SVN.

the file 'mycoolapp.ini' from the relevant target would be symlinked:

$ ln -s /cnf/targets/localhost.jochem/php/mycoolapp.ini /etc/php.d/mycoolapp.ini

this would need to be done only once rather at the beginning of each shell session.

>
> 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

Re: another question on setting include paths for a project

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

Re: another question on setting include paths for a project

On 23 March 2010 13:11, Robert P. J. Day 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 bootstr=
ap.
>>
>> /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 lo=
ts
> 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 star=
t
> 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
> --
>
> ==================== =====
==================== =====3D=
==================== ===3D
> Robert P. J. Day                 =
              Waterloo, Ontario, CANADA
>
>            Linux Consulting, Training and K=
ernel Pedantry.
>
> Web page:                   =
                    =C2=
=A0  http://crashcourse.ca
> Twitter:                   =
                    http:=
//twitter.com/rpjday
> ==================== =====
==================== =====3D=
==================== ===3D
>
> --
> 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.



--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: another question on setting include paths for a project

On Tue, 23 Mar 2010, Richard Quadling wrote:

> 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.

sure, but deep down, you're still doing what i'm claiming has to be
done at some point -- *explicitly* identifying the target location.
you're just doing it in a different way, which is fine and might be
what i'm after.

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

Re: another question on setting include paths for a project

On 23 March 2010 16:39, Robert P. J. Day wrote:
> On Tue, 23 Mar 2010, Richard Quadling wrote:
>
>> 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.
>
>  sure, but deep down, you're still doing what i'm claiming has to be
> done at some point -- *explicitly* identifying the target location.
> you're just doing it in a different way, which is fine and might be
> what i'm after.
>
> rday
> --
>
>
> ==================== =====
==================== =====3D=
==================== ===3D
> Robert P. J. Day                 =
              Waterloo, Ontario, CANADA
>
>            Linux Consulting, Training and K=
ernel Pedantry.
>
> Web page:                   =
                    =C2=
=A0  http://crashcourse.ca
> Twitter:                   =
                    http:=
//twitter.com/rpjday
> ==================== =====
==================== =====3D=
==================== ===3D
>

You could of course simply look in the entire file system for a key
file, but ... well ... maybe not!

The thing about an env_var is that it is pretty much no different to
an INI setting in this regard.

By having the setting "closer" to the code using it (i.e. I see the
location in the batch file used to run the testing, I see the location
in the require_once() line in the main script), it is easier to see
the location. An env_var or an ini setting is quite some distance away
from the code and may seem "magical".

What I'm not sure is how you can ever get away without explicitly
declaring the location unless you always put the files in the include
path.


--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php