Dumb question or what? (Thank you)

Hey Guys, Whooh, now THAT was a nice response to a dumb doubt. Thank you, (ALL of you) who responded and cleared up that doubt once and for all, it was nice to hear about examples of other apps using many includes and your own experiences + techniques/tricks of how you are handling includes. Not only did I get all that but also got advise and ideas, things to avoid and lots more. Thanks guys, hopefully someday I can answer your problem/query on the list. Cheers, -Ryan ----- Original Message ----- From: "Justin French" <justin@indent.com.au> To: "Ryan A" <ryan@jumac.com> Sent: Sunday, May 04, 2003 2:57 AM Subject: Re: [PHP] Dumb question or what? > on 04/05/03 11:19 AM, Ryan A (ryan@jumac.com) wrote: > > > I am kind of new to php coming from a java servlets background and > > welll....I have fallen for PHP like a sailer for a hooker after a few months > > at sea :-) > > > > I am going a little crazy with the include() calls and have a template with > > around 7 includes in the pages like > > header.php > > footer.php > > left.php > > right.php > > menu.php > > news.php > > misc.php > > includes() are pretty quick and pain free... especially if each include is > just more HTML, not PHP with huge database queries. > > Most of my sites are built off my own CMS, which currently has about 4 basic > includes for 99% of the pages (plus embedded includes, which there are about > 5-6), plus any additional includes that each specific page/script might > require, most of which are being parsed by PHP, and half of which would have > database queries and other "slowish" code. > > I have never noticed any performance problems (even on my old P1 133 test > server on my LAN). > > > Of course, these pages CANNOT be running as fast as single, static HTML > pages, but the benefits outweigh the cause. > > > Think about some of the fusebox-style architecture (and some of the > templating languages out there) which have MANY MANY MANY includes... no > problems at all. phpMyAdmin would be another good example of a popular > application running with MANY includes. > > > One thing I would suggest (a personal preference only) is to name your > included files differently to your main scripts. This way: > > a) you can easily tell which are "pages" and which are "portions of pages" > b) you can use apache to block http access to the "portions" > c) you can designate static HTML pages differently to PHP scripts and other > includes > > Example > > > All my PAGES are named *.php > All my includes that use PHP are named *.inc, and are stored in an /inc/ > directory > All my static HTML includes are named *.html > All my static TEXT includes are named .txt > > > Then, in my Apache .htaccess file, I block .html, .inc, and .txt files from > being served directly over http. > > This helps make sure that > > a) little snippets of PHP code don't get executed out of context > b) people don't / can't readily access sensitive data (like passwords) that > are in include files, or access chunks of text and HTML which are only > intended to be included by users in some circumstances (like members-only > stuff) > > > Just a personal preference, but it helps me :) > > > Justin > > > > > > > > > > > all those files are just static blocks of html code nothing dynamic...my > > question is (since you guys are much more experienced than me and are using > > PHP longer) will this be too big a load on the server and/or slow down my > > page loading a lot in the long run? > > I have a high speed broadband connection so to me it really does not matter > > but to the average joe... > > I have around 13 pages on the whole site... > > > > your views are appreciated. > > > > Cheers, > > -Ryan > > >