Re: Question about best practices with regard to site structure and include/include_path
| From: | George Wilson | Date: | Tue, 10 Dec 2013 20:02:07 +0000 |
| Subject: | Re: Question about best practices with regard to site structure and include/include_path | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-322561@lists.php.net to get a copy of this message | ||
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.
On Tue, Dec 10, 2013 at 10:02 AM, George Wilson <rmwscbt@gmail.com> wrote:
> 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.