RE: [PHP] PHP Application Structre
| From: | Arno Kuhl | Date: | Mon, 10 May 2010 11:15:11 +0000 |
| Subject: | RE: [PHP] PHP Application Structre | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-305033@lists.php.net to get a copy of this message | ||
-----Original Message-----
From: Alex Major [mailto:php@allydm.co.uk]
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