Question about best practices with regard to site structure and include/include_path

[George Wilson]

Greetings all,
I apologize if this email is really long. I manage a code base which
has been maintained by at least 5 lead developers over the last 3
years- all coming from different backgrounds and approaches. Moral of
the story- it is a scary ugly mess of a code base. I am in the process
of refactoring the site to make things cleaner and more organized with
the eventual goal of assuming an MVC or similar flavored OO
architecture but that is a long term goal. I have about 485 source
files to work with total.

Here is the question. Step one in my plan is to reorganize everything
and to centralize all of the site configuration. Eventually I will
move to using namespaces and autoloaders but for now I am required to
stick with include/requires. I am weighing out the costs and benefits
of using include/require with absolute paths defined vs. using
set_include_path.

My very strong inclination is to use set_include_path and specifify a
configuration folder (which I have already started using) and have
every script include a script which points to that. I was wondering if
there are any potential issues I should remain mindful of. I ask
because as I have been looking into this feature, I see a lot of
conflicting information regarding best practices. Here are the
parameters I have to work with (for better or worse):

1) I am not permitted to use a .htaccess file per department policy- I
may be able to set a path variable in httpd.conf but kinda want to
avoid it since server configurations make management very nervous.
2) Namespaces, while a long term goal, are not feasible right now
3) The directory structure will change in time, I need a solution
which refactors cleanly and safely (dynamically is nice too)

Thank you in advance.

[George Wilson]

Please disregard my question for now. I found a bunch of new
information which I think might provide the answer and save you guys
the keystrokes. I will follow up with what I find.

Post by George Wilson
Greetings all,
I apologize if this email is really long. I manage a code base which
has been maintained by at least 5 lead developers over the last 3
years- all coming from different backgrounds and approaches. Moral of
the story- it is a scary ugly mess of a code base. I am in the process
of refactoring the site to make things cleaner and more organized with
the eventual goal of assuming an MVC or similar flavored OO
architecture but that is a long term goal. I have about 485 source
files to work with total.
Here is the question. Step one in my plan is to reorganize everything
and to centralize all of the site configuration. Eventually I will
move to using namespaces and autoloaders but for now I am required to
stick with include/requires. I am weighing out the costs and benefits
of using include/require with absolute paths defined vs. using
set_include_path.
My very strong inclination is to use set_include_path and specifify a
configuration folder (which I have already started using) and have
every script include a script which points to that. I was wondering if
there are any potential issues I should remain mindful of. I ask
because as I have been looking into this feature, I see a lot of
conflicting information regarding best practices. Here are the
1) I am not permitted to use a .htaccess file per department policy- I
may be able to set a path variable in httpd.conf but kinda want to
avoid it since server configurations make management very nervous.
2) Namespaces, while a long term goal, are not feasible right now
3) The directory structure will change in time, I need a solution
which refactors cleanly and safely (dynamically is nice too)
Thank you in advance.

[George Wilson]

I have no idea if these emails are actually being received by the list
(would someone mind confirming?) but after some consideration, I think
I have a plan I can sell to management.
It seems that the safest way to handle this is to just go ahead and
add my configuration script directory to the include path and block
web access to it. If I sell it on the basis of easing the transition
to an MVC architecture, I think I can get them to go for it It seems
like this is the only reasonable way to avoid coding relative paths to
the configuration directory where my configuration scripts are
located. A lot of the motivation for this project is to make
fail-overs easier anyway and avoid downtime. If anyone has any input I
would be glad to hear it. For the sake of historical documentation I
will post my plan execution and results a little later down the road.

Post by George Wilson
Please disregard my question for now. I found a bunch of new
information which I think might provide the answer and save you guys
the keystrokes. I will follow up with what I find.

Post by George Wilson
Greetings all,
I apologize if this email is really long. I manage a code base which
has been maintained by at least 5 lead developers over the last 3
years- all coming from different backgrounds and approaches. Moral of
the story- it is a scary ugly mess of a code base. I am in the process
of refactoring the site to make things cleaner and more organized with
the eventual goal of assuming an MVC or similar flavored OO
architecture but that is a long term goal. I have about 485 source
files to work with total.
Here is the question. Step one in my plan is to reorganize everything
and to centralize all of the site configuration. Eventually I will
move to using namespaces and autoloaders but for now I am required to
stick with include/requires. I am weighing out the costs and benefits
of using include/require with absolute paths defined vs. using
set_include_path.
My very strong inclination is to use set_include_path and specifify a
configuration folder (which I have already started using) and have
every script include a script which points to that. I was wondering if
there are any potential issues I should remain mindful of. I ask
because as I have been looking into this feature, I see a lot of
conflicting information regarding best practices. Here are the
1) I am not permitted to use a .htaccess file per department policy- I
may be able to set a path variable in httpd.conf but kinda want to
avoid it since server configurations make management very nervous.
2) Namespaces, while a long term goal, are not feasible right now
3) The directory structure will change in time, I need a solution
which refactors cleanly and safely (dynamically is nice too)
Thank you in advance.

[mauro gullino]

received


mg.

Post by George Wilson
I have no idea if these emails are actually being received by the list
(would someone mind confirming?) but after some consideration, I think
I have a plan I can sell to management.
It seems that the safest way to handle this is to just go ahead and
add my configuration script directory to the include path and block
web access to it. If I sell it on the basis of easing the transition
to an MVC architecture, I think I can get them to go for it It seems
like this is the only reasonable way to avoid coding relative paths to
the configuration directory where my configuration scripts are
located. A lot of the motivation for this project is to make
fail-overs easier anyway and avoid downtime. If anyone has any input I
would be glad to hear it. For the sake of historical documentation I
will post my plan execution and results a little later down the road.

Post by George Wilson
Please disregard my question for now. I found a bunch of new
information which I think might provide the answer and save you guys
the keystrokes. I will follow up with what I find.

Post by George Wilson
Greetings all,
I apologize if this email is really long. I manage a code base which
has been maintained by at least 5 lead developers over the last 3
years- all coming from different backgrounds and approaches. Moral of
the story- it is a scary ugly mess of a code base. I am in the process
of refactoring the site to make things cleaner and more organized with
the eventual goal of assuming an MVC or similar flavored OO
architecture but that is a long term goal. I have about 485 source
files to work with total.
Here is the question. Step one in my plan is to reorganize everything
and to centralize all of the site configuration. Eventually I will
move to using namespaces and autoloaders but for now I am required to
stick with include/requires. I am weighing out the costs and benefits
of using include/require with absolute paths defined vs. using
set_include_path.
My very strong inclination is to use set_include_path and specifify a
configuration folder (which I have already started using) and have
every script include a script which points to that. I was wondering if
there are any potential issues I should remain mindful of. I ask
because as I have been looking into this feature, I see a lot of
conflicting information regarding best practices. Here are the
1) I am not permitted to use a .htaccess file per department policy- I
may be able to set a path variable in httpd.conf but kinda want to
avoid it since server configurations make management very nervous.
2) Namespaces, while a long term goal, are not feasible right now
3) The directory structure will change in time, I need a solution
which refactors cleanly and safely (dynamically is nice too)
Thank you in advance.

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

[leam hall]

More reading:

http://www.nyphp.org/phundamentals/3_PHP-Site-Structure-Where-Locate-Includes

Leam

[tamouse pontiki]

Post by George Wilson
I have no idea if these emails are actually being received by the list
(would someone mind confirming?)

You can always check the news feed: http://news.php.net/php.general