_____  

From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 10 May 2010 01:58 PM
To: a...@dotcontent.net
Cc: 'Alex Major'; 'php-general General List'
Subject: RE: [PHP] PHP Application Structre


On Mon, 2010-05-10 at 13:15 +0200, Arno Kuhl wrote: 

-----Original Message-----

From: Alex Major [mailto:p...@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








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

Reply via email to