Re: [PHP] another question on setting include paths for a project
On 23 March 2010 16:39, Robert P. J. Day rpj...@crashcourse.ca 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 -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday 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. -- - 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=ZEND002498r=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: [PHP] 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: [PHP] another question on setting include paths for a project
On 23 March 2010 13:11, Robert P. J. Day rpj...@crashcourse.ca 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=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
Re: [PHP] 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
[PHP] 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: [PHP] another question on setting include paths for a project
On 22 March 2010 14:18, Robert P. J. Day rpj...@crashcourse.ca 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=ZEND002498r=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: [PHP] 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: [PHP] 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: [PHP] 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: [PHP] 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: [PHP] another question on setting include paths for a project
On 22 March 2010 15:28, la...@garfieldtech.com la...@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=ZEND002498r=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: [PHP] another question on setting include paths for a project
On 22 March 2010 14:51, Robert P. J. Day rpj...@crashcourse.ca 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?
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
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
--
-
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=ZEND002498r=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
Fwd: Re: [PHP] 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 +
Van: Jochem Maas joc...@iamjochem.com
Aan: Robert P. J. Day rpj...@crashcourse.ca
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:
project/cnf/targets/localhost.jochem/php
project/cnf/targets/localhost.jochem/httpd
project/cnf/targets/localhost.charlie/php
project/cnf/targets/localhost.charlie/httpd
