-----Original Message----- From: richard gray [mailto:rich@xxxxxxxxxxxx] Sent: 10 May 2010 07:05 PM Subject: Re: Re: PHP Application Structre On 10/05/2010 18:17, Ashley Sheridan wrote: > It makes sense sometimes to have different files for different > sections of a website. For example, blog.php, gallery.php, cart.php > could deal with the blog, gallery and shopping cart sections for an > artists website. Yes, it could all be achieved with one script > handling everything, but sometimes when the areas of the site differ > greatly, it results in a lot of extra code to deal with pulling in the > right template and content parts. I've always favoured only including > the code a page needs rather than a huge amount of stuff that it doesn't. > this isn't necessarily true - the architecture I've developed uses a single dispatch script (works fine with the mod rewrite option 2 scenario as well) - this script does general checks/security/filters etc then simply determines what page/function the user wants from the request ($_GET/$_POST parameter) and passes control to the specific handler via including the relevant controller module. The controller module is responsible for which template is required and loads up specific classes needed to process the request etc so each module just loads its own stuff and nothing else so there's no overhead. This method also has a small extra benefit that the web server document root just has a very simple 2 liner script instead a myriad of php scripts... if the webserver is misconfigured then someone who sees the source code doesn't get to see much.. Just my 0.02 Euros Cheers Rich -- This is the design I also use. My single entry point (or dispatch script) is only 12 lines of code and never changes, even though the application is constantly updated and expanded. It doesn't load 100's of KB, instead relies on the next (module) layer to load its own requirements. But it does ensure the environment is correct, input checked, db connected, core api's loaded. It's really six of one and half-a-dozen of the other because all designs end up at more or less the same point, but for me this was the most efficient, flexible and expandable design after trying several approaches. Even major design changes like registering modules and scripts and adding mod-rewrite can be done without needing to change the entry script. If another completely unrelated app is ever added I'll just call it's script as Ashley described. The design allows for some interesting options, like a single installed app running multiple domains. We use cents and they're worthless... Cheers Arno -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
