Re: [PHP] PHP Application Structre
On 12 May 2010 07:10, Kevin Kinsey k...@daleco.biz wrote:
Ashley Sheridan wrote:
On Tue, 2010-05-11 at 08:48 +0530, chetan rane wrote:
Hi all,
mod rewrite was actually inrduced to have search engne frendly urls.
hnce if you want a seo site then you have to use options 1 2. using
smarty or any templating engine for readibility is not total true.
one of the major advantages of using template engines is caching
I've read some {disparaging?) comments on option 2, but I've
got a question, or point, about that. I'm not at all sure that
you have to use mod_rewrite at all, can't you just use a
FORCETYPE directive on your handler script(s)?
I've certainly got some work in the form:
somesite.com/scriptname/var1/var2/var3
that seems to work well with no use of the rewrite module.
And why wouldn't you want to use mod_rewrite? It's an extremely
powerful tool that does the job really well.
Regards
Peter
--
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
On Wed, May 12, 2010 at 10:16:04AM +0200, Peter Lind wrote:
On 12 May 2010 07:10, Kevin Kinsey k...@daleco.biz wrote:
Ashley Sheridan wrote:
On Tue, 2010-05-11 at 08:48 +0530, chetan rane wrote:
Hi all,
mod rewrite was actually inrduced to have search engne frendly urls.
hnce if you want a seo site then you have to use options 1 2. using
smarty or any templating engine for readibility is not total true.
one of the major advantages of using template engines is caching
I've read some {disparaging?) comments on option 2, but I've
got a question, or point, about that. I'm not at all sure that
you have to use mod_rewrite at all, can't you just use a
FORCETYPE directive on your handler script(s)?
I've certainly got some work in the form:
somesite.com/scriptname/var1/var2/var3
that seems to work well with no use of the rewrite module.
And why wouldn't you want to use mod_rewrite? It's an extremely
powerful tool that does the job really well.
Because your public internet server disables its use.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
Peter Lind wrote:
On 12 May 2010 07:10, Kevin Kinsey k...@daleco.biz wrote:
Ashley Sheridan wrote:
On Tue, 2010-05-11 at 08:48 +0530, chetan rane wrote:
Hi all,
mod rewrite was actually inrduced to have search engne frendly urls.
hnce if you want a seo site then you have to use options 1 2. using
smarty or any templating engine for readibility is not total true.
one of the major advantages of using template engines is caching
I've read some {disparaging?) comments on option 2, but I've
got a question, or point, about that. I'm not at all sure that
you have to use mod_rewrite at all, can't you just use a
FORCETYPE directive on your handler script(s)?
I've certainly got some work in the form:
somesite.com/scriptname/var1/var2/var3
that seems to work well with no use of the rewrite module.
And why wouldn't you want to use mod_rewrite? It's an extremely
powerful tool that does the job really well.
Well, again, I'm not purporting to be an authority, but the
first thing that comes to mind is that my reasoning would be
much the same as my reasoning in building stuff: I've got a nice
STIHL chainsaw, but I don't need it to cut two-by-fours, and
I've got access to a Hole Hawg but don't need it to make a
path for a CAT5 cable. I guess you could call the concept
avoiding overkill, but I'm not cognizant enough with the
inner workings of Apache to know really how much of a hit
the rewrite module makes. I suppose, in terms of computing, it's
kind of similar to a Unix philosophy: small tools that
do one job without extra fluff.
KDK
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
On 12 May 2010 17:07, Paul M Foster pa...@quillandmouse.com wrote: Because your public internet server disables its use. And once more I'm reminded of just how happy I am with my VPS and my dedicated server. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
On 12 May 2010 17:17, Kevin Kinsey k...@daleco.biz wrote: Well, again, I'm not purporting to be an authority, but the first thing that comes to mind is that my reasoning would be much the same as my reasoning in building stuff: I've got a nice STIHL chainsaw, but I don't need it to cut two-by-fours, and I've got access to a Hole Hawg but don't need it to make a path for a CAT5 cable. I guess you could call the concept avoiding overkill, but I'm not cognizant enough with the inner workings of Apache to know really how much of a hit the rewrite module makes. I suppose, in terms of computing, it's kind of similar to a Unix philosophy: small tools that do one job without extra fluff. Doing it in PHP is like to be doing it with extra fluff. Mod_rewrite is designed for rewriting and it does it well. Doing the same job in PHP is likely to use more resources and be more complex. In short: using mod_rewrite for url rewriting is not overkill - it's using the proper tool for the job. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
On Tue, 2010-05-11 at 08:48 +0530, chetan rane wrote: Hi all, mod rewrite was actually inrduced to have search engne frendly urls. hnce if you want a seo site then you have to use options 1 2. using smarty or any templating engine for readibility is not total true. one of the major advantages of using template engines is caching On 5/11/10, David McGlone da...@dmcentral.net wrote: On Monday 10 May 2010 13:04:36 richard gray wrote: 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.. This thread makes me wonder if using Smarty is smart. Does anyone here use a templeting system such as smarty or am I the only one? -- Blessings, David M. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Sent from my mobile device with regards, Chetan Dattaram Rane Mob : +91 9766646714 Phone: 0831-2462055 Aside from the fact that I've yet to find any actual evidence that search engines treat what most people consider 'search engine friendly' urls any different from the 'unfriendly dynamic' ones. Next time you search for something online have a look at the URLs and see how many belong to forums with dynamic URLs. More than you'd think I would imagine, but it does go a long way to prove that most search engines don't give much credence to the URL these days. Of course, it does help if your keywords are in the URL, but I've not noticed much of a difference between: somesite.com/page-about-subject and somesite.com/?page=page-about-subject Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] PHP Application Structre
Ashley Sheridan wrote:
On Tue, 2010-05-11 at 08:48 +0530, chetan rane wrote:
Hi all,
mod rewrite was actually inrduced to have search engne frendly urls.
hnce if you want a seo site then you have to use options 1 2. using
smarty or any templating engine for readibility is not total true.
one of the major advantages of using template engines is caching
I've read some {disparaging?) comments on option 2, but I've
got a question, or point, about that. I'm not at all sure that
you have to use mod_rewrite at all, can't you just use a
FORCETYPE directive on your handler script(s)?
I've certainly got some work in the form:
somesite.com/scriptname/var1/var2/var3
that seems to work well with no use of the rewrite module.
Aside from the fact that I've yet to find any actual evidence that
search engines treat what most people consider 'search engine friendly'
urls any different from the 'unfriendly dynamic' ones. Next time you
search for something online have a look at the URLs and see how many
belong to forums with dynamic URLs. More than you'd think I would
imagine, but it does go a long way to prove that most search engines
don't give much credence to the URL these days.
Of course, it does help if your keywords are in the URL, but I've not
noticed much of a difference between:
somesite.com/page-about-subject
and
somesite.com/?page=page-about-subject
I think that this may be an artifact of an earlier time. There
was a time when SE's didn't do so well with query strings, but it'd
be a little silly to think their owners didn't realize this and left
things exactly the way they were back in 2002 ... wouldn't it?
My $0.02,
Kevin Kinsey
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Application Structre
-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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP] PHP Application Structre
On 10 May 2010 13:58, Ashley Sheridan a...@ashleysheridan.co.uk wrote: 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 Option 1 with option 2 as a sidedish. Option 3 is a nightmare in my experience - a proper MVC approach is much better to work, maintain and assure the security of. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Application Structre
_ 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
