Running a template system...

One page to rule them all?

[mipapage]

Hey all... here's the story:

Situation
I have a site setup right now where there is a separate 'somepage.php' for each page of the site. Some pages have flat content and others have funtions that are triggered based on URL parameters. I use includes for header and footer etc. on each page.

I clean up the url parameters using rewrite rules, such that right now I have about 9 rules in an .htaccess file that apply to the different pages.

Question
I'm wondering, rather than having separate files for each page, would it be better to have a main template.php which handles all requests? I do this on other sites, but these sites are orders of magnitude more simple.

Using this method I have one rewrite rule that takes everything after the root url and passs it to PHP. PHP then sorts out what should be delivered.

The main benefit of this method is easier error handling. Template.php checks the url vs. a list of valid values and either serves the correct page or an error page.

In Summary...

1. Would it be better to have a main template.php which handles all requests?
   
2. Is there any obvious downfall to either method that I am missing?
3. Is one method faster than the other?

Any feedback appreciated!

[ergophobe]

I would not claim to have *the* answer, but some thoughts.

I think the general idea is pretty good.
- mod_rewrite sends everything to one file.
- That file then figures out how to serve up the url
-- is it a valid filename and we serve it straight up (sometimes a useful option)?
-- is it a valid directory name and we serve up its index page?
-- is it a valid URI that we need to parse and feed to our template?

My opinion is, so far so good. Where I disagree though, is that this file should also be *the* template. Rather, it should find the proper file and then feed that to a template. Why?

1. I like templates to have little or no processing beyond variable substitution. So it's mostly HTML with variable content filled in using variables defined in other files.

2. One template may not be appropriate for all pages on your site. This way you can have a different template for, say, any URI with the "/photo-gallery/" in the path.

Tom

[mipapage]

Hey Tom,

thanks for the feedback - great ideas - I hadn't thought of using >1 template, I guess bacause the need hadn't arisen yet, but now the wheels are turning... :-]

Rather, it should find the proper file and then feed that to a template.

Time to hit the couch and let that one sink in...

[ergophobe]

Just my ideas. I'd be curious how others build template systems.

One advantage I forgot to mention. If the template has nothing but variable substituion, a designer who knows nothing about php can easily work on the layout, mess with the stylesheets and so on. All s/he has to know is that the little words with $ in front of them will bring in the actual content.

[jatar_k]

I seldom let the designer work on my templates so I build with most of the processing there. An intelligent template that knows where it is, what it's doing and possibly why it exists. ;)

It is always a bit of a game to make it be faster than the content it deals with.

I think, as far as your situation goes mipapage, I agree completely with Tom's ideas. Particularily serving it to a specific template. It then becomes more of a control script and gives you the most flexibility.

[mipapage]

Thanks you two. I like the idea that Tom outlined. I was mostly concerned that I may be doing something inherently 'slow'.

The control aspect of having the one page, well, 'in control' make things a whole lot easier.

[jamie]

i do exactly that mipapage.

one script from which all pages are generated, mod_rewrite redirects everything (.*) to html.php/$1. and just like tom says, for layouts of different pages, i include the appropriate file into html.php - photos, news, sitemap, etc.

but all html is kept in the templates where i substitute the {$variables} in twirly brackets. our designer doesn't programme, so i kept as much 'code' out of the template as possible. this is also a help for different language versions. i just translate the main template and the db fields, i don't have to look around the php scripts changing 'the' for 'la' ;-) i also like the fact that i only have to edit one file to make display changes.

i found these simple template functions [devarticles.com] a great help whilst learning.

the only pitfall with this is that 404s for documents don't show up in your logs. because the ErrorDoc 404 is never given a chance to handle the request because everything is redirected through your php script, regardless of whether it exists or not. if you query the db and find out the page does not exist, you can still send the client a perfect 404 header (this includes search engines) but this registers in your logs as a 200. to get round this i send myself a mail if the db query comes up empty.

good luck

[mipapage]

Thanks jamie,

I'm doing the same with errors - both script errors and 404's have become a bit of a pet project of mine ever since I lost a week (give or take ;-]) troubleshooting one of my first pieces of code.

I'm glad to hear that this method is commonly practiced!

[ergophobe]

404s for documents don't show up in your logs.

But you do all processing before doing any output, right? Therefore, you can always send a 404 header [php.net] and not crash your app with a "headers already sent" error.

Tom

[mipapage]

For sure, that's what I'm up to!

That is, in fact, the reason that I want to use this method.

It's for a real-estate site and they move properties fast - As the site will be SE friendly, I can see some serious 404 pages happening as places get sold - so, I'm looking to add some nice "this is sold, how about this?" error handling to the site.

nice clean-up Tom!

[jamie]

>> "this is sold, how about this?"

i like that idea!

tom, exactly. the clients and any search engines receive correct headers, but unfortunately apache error handling is bypassed. jim from the apache forum put me on to that in this post [webmasterworld.com]

[ergophobe]

That's true. It won't show up in your logs which is kind of a bummer. On the other hand, it's super easy to add a column into the DB for page views and you will get some of the same info. You're right, though, if you want to record page views, referrer, time, etc etc etc, you would lose something.

[mipapage]

Thanks everyone, system works great!

[jamie]

i believe that this system is also slightly quicker than having a separate php file for each page, because the one php script which generates all the pages is called so often it is kept cached in ram = less disk seeks.

don't quote me on that though ;-) and i certainly can't tell a difference

glad you got it sorted