On 5/10/2010 6:39 AM, Alex Major wrote:
Greetings all,
This question basically surrounds how you structure your PHP applications,
whether it changes depending on what you're doing and which you'd favour. I
have a feeling it'll come down to a question of personal taste, but on the
off-chance there's a best practice I'll ask anyways.
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?
Hopefully someone can shed some insight into which is the recommended
approach and why. I've been building bigger and bigger sites so having a
solid foundation is becoming more and more important.
Thanks for any help/feedback, I hope I've been clear.
Alex.
Here is my take on your 3 options:
1] Basically the approach taken by so-called CMS systems like Joomla. Three
major problems. One, everything is in one core and DB; so if there is a major
bug, crash, hack, whatever, it is hell to repair. If the site is very active,
backups can be a problem trying to recover anything that has changed since the
last backup. Also, sometimes bugs and hacks can exist for a relatively long time
before they manifest themselves. Finding when such first occurred and then
backing up from there can be damn near impossible. Two, any changes to the core
can have unforeseen consequences somewhere in the site. Three, if the core
breaks the whole site is down.
2] I use essentially this approach. But, don't use mod_rewrite. It is an
unnecessary complication. Remember in the PHP world the initial php page "owns"
the session. So, the current working dir is where the php file is. I like the
fact that all pages are called by a URL name e.g.; www.foo.com/bar/filex.php and
I save the pages data in a sub directory or DB just for it. e.g.,
www.foo.com/bar/data/dataFile.db. All of my application types e.g., simple html
pages, sign up registries, etc. each have their own config and functions file,
etc. in a separate dir/ Each page can have a custom css, images, etc. in it's
dir and for special situations, I can write a php that performs some special
functions and then calls the common application script. If the page becomes
obsolete, I simply delete the dir and subdir. When I update a application type
core code, e.g., Signups, I don't need to worry about affecting regular html
page types.
Here is one of my typical "calling files
"www.foo.com/Seminars/Running_Economy.php":
<?php
require_once $_SERVER['DOCUMENT_ROOT'] . '/editPageSR/editPageSR.php'; //do not change
?>
Can't get any simpler.
3} Unless the site is small and has few pages and applications, it is almost
impossible to maintain.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
