For ease of development and maintenance many prefer to put the whole application in a single script - TBS's simple and powerful conditional blocks (among other things) makes this more attainable than ever.
Now lets worry about server performance -- the way I cache pages does depend on the content of the page and incorporating all content views in a single script poses an interesting problem. I worked the TBS subscript technique till I was blue in the face - yes it works, but it spreads the code and templates far and wide - not a happy camper till the obvious dawned. Perhaps not new for many of you - but I pass it along for the newbies to learn from.
The 'obvious lightbulb moment' was realizing that all of the logic for establishing the page content was in fact the same logic I could use for controilling the cache content. Shazam! Just mke the cacheid and cache time variables!!!
Now, here's how I create individual cache files (even though it's for the same master script) based on the content rendered.
<?php
// check tha vars passed back from the rendered appl page
// These control the content for this instance of the script/application
if(isset($id)){ // link clicked for an individual data record
$cacheid = "contactsid$id";
$cachesecs = $idsecs = 180;
}elseif(isset($letter) ){ // link clicked to view a subset/categ of data
$cacheid = "contactsletter$letter";
$cachesecs = 80;
$pagelabel = "The $letter's ";
}else{
$cacheid = "contactsall"; // DEFAULT show all for default view
$cachesecs = 0;
$pagelabel = "All contacts ";
}
$TBS = new clsTinyButStrong ;
//$TBS->LoadTemplate('basic_page2.html') ;
$TBS->LoadTemplate(basename($_SERVER['SCRIPT_NAME'], ".php").".html") ;
//$TBS->Render(TBS_NOTHING);
// == here's the tricky bit ==
// Creating different cache files based on vars above
if (!$TBS->CacheAction($cacheid, $cachesecs)) { // to check cache
// do all the sql and merges here
$TBS->Show
} // end the if(cache) test
?>
|
HTH,
TomH