_____ From: Ashley Sheridan [mailto:ash@xxxxxxxxxxxxxxxxxxxx] Sent: 10 May 2010 01:58 PM To: arno@xxxxxxxxxxxxxx Cc: 'Alex Major'; 'php-general General List' Subject: RE: PHP Application Structre On Mon, 2010-05-10 at 13:15 +0200, Arno Kuhl wrote: -----Original Message----- From: Alex Major [mailto:php@xxxxxxxxxxxx] Sent: 10 May 2010 12:39 PM >From what I've seen and used, there seem to be three distinct ways of going about it. 1) Using a 'core' class which has a request handler in it. All pages in the site are accessed through that one page, e.g. http://www.somesite.com/index.php?page=ViewUser http://www.somesite.com/index.php?page=ViewProduct This is one that I've personally used most after becoming familiar with a bulletin board system several years ago. It means that pages are easily created as all the template/session/database handling is done by the central class. 2) Using SE friendly URL's like: http://www.somesite.com/products/22012/cool-game/ http://www.somesite.com/products/22013/other-game/ This approach seems to be becoming more common on the sites I frequent, however by accounts I've read it seems to be more intensive on apache as it requires a mod-rewrite function. 3) Using different PHP files for each page: http://www.somesite.com/viewproduct.php?product=.... http://www.somesite.com/viewuser.php?user=... This would appear to be the least developer friendly option? Alex. ============= The second option doesn't really belong here, because you could go for option 1 or option 3, and then decide whether to hide your implementation behind a mod-rewrite. Option 2 would rather be part of a separate question "what is the cost/benefit of using mod-rewrite". Cheers Arno Personally, I go with option 3 (as Arno said, option 2 isn't really an alternative option, it's something you can use with either 1 or 3) Consider a basic website with a small shopping cart and a blog. It would seem crazy to have all the logic needed for the blog and the cart being pulled in by PHP everytime you just needed to display a contact page. Far easier to keep everything a bit more modular. That way, if you need to update something, you update only a small part of the site rather than some huge core file. But, if your needs are even more simple, say it's just a very small brochure website you have, then running everything through a single index.php might not be such a bad idea. Thanks, Ash http://www.ashleysheridan.co.uk ========================== There are many approaches to this, and I think your final design will largely be determined by what you want to do, and your own skill and experience. If you want to initialise your application, check input and load all your base api functions before calling the specific script (function) to handle the query, then maybe you can consider using a single entry point for your application. It can simplify your design and maintenance, and there are ways to ensure that access to your scripts have been initialised via the single entry point. Careful design can allow you to add new modules/scripts/whatever without having to update your single entry point each time (look at some open-source apps for examples). It also allows you to move your entire application to some place outside the document root and leave only the entry script open to the public, which can add a bit of extra security to your application. Personally I use two entry-points, one for admin and one for everything else. Then besides graphics, flash and javascript, everything else is put someplace outside the document root. The reason I settled on that approach was because the admin script can handle all the slow heavy security-checking stuff and loading additional admin api's, while the general script can be small, fast and lightweight, but won't allow any access to the admin functions. Neither script needs to be updated when adding to or changing the main application. Cheers Arno
