Re: [SMARTY-DEV] Once again: Solution for {nocache} blockfunction?!

From: Date: Wed, 19 Feb 2003 15:46:34 +0000
Subject: Re: [SMARTY-DEV] Once again: Solution for {nocache} blockfunction?!
References: 1 2 3 4  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-738@lists.php.net to get a copy of this message
Hi Monte > {SMARTY_PRECOMPILE_TAG cacheme foo="blah" SMARTY_PRECOMPILE_TAG} > {include file="foo.tpl"} Sure something like this is needed. Just wanted to keep my examples simple ;-) > I don't see how your method is any different than mine... except calling > "precompiled/compiled" vs. "compiled/cached" The difference is only small. But as far as I have understood you just include (I mean the PHP function) the compiled file. Then the complete output is stored in the .cache file. This .cache file is finally displayed. I have just extended this functionality so the .tpl still contains Smarty tags and gets compiled again instead of just included. (This is why I called it precompiled in my examples to show there's a difference between normal .tpl files). The resulting file is the .tpl after all. Include it (again the PHP function is meant) and the output is html with cached and non-cached parts. This is why I like this idea. It would be easier to implement than everything other I've heard or read about so far. Don't you think this could solve the non-cached blocks and functions problematic? Btw: I thought I post my ideas here not because I have a solution or an impression of what the result will be. I just thought about a way to _implement_ it. This is why I created the diagramm. (http://cmsng.sourceforge.net/TemplateCaching.png). It helped me to understand the problematic. I have created it for Smarty (not for any other system). Perhaps it's not a good idea but how would you implement your method? bye, André "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag news:1045666228.28271.17.camel@lena.ispi.prv... > One problem I see is the syntax of the precompiled template tags, they > can get mixed up with output. > > example: > > index.tpl > --------- > > {echo text="this is a test"} > {cacheme foo="blah"} > {ldelim}include file="foo.tpl"{rdelim} > > index.ppl.php > ------------- > <?php echo "this is a test" ?> > {cacheme foo="blah"} > {include file="foo.tpl"} > > > oops, now that literal tag is going to get parsed, not good! > > That is why the Smarty md5 string is used in the current cache files, to > be sure the insert tags are not part of the output. > > Therefore, maybe the precompiled files should have tags like: > > index.ppl.php > ------------- > <?php echo "this is a test" ?> > {SMARTY_PRECOMPILE_TAG cacheme foo="blah" SMARTY_PRECOMPILE_TAG} > {include file="foo.tpl"} > > > I don't see how your method is any different than mine... except calling > "precompiled/compiled" vs. "compiled/cached" > > Monte > > > On Wed, 2003-02-19 at 02:59, André Rabold wrote: > > Thanks for answering :-) > > > > > index.tpl.php > > > ------------- > > > > > > <?php smarty_function_foo("blah"); ?> > > > <?php smarty_function_foobar("blah"); ?> > > > > > > There are some things to get through, such as how to recognize the > > > cached and non-cached elements of index.tpl.php, and how to handle > > > multiple templates included within each other in the cache files (if > > > there are several templates included in a non-cached block, do they > > > still all go in the same cache file?) > > > > > > > This is the reason why I would prefer two compiling steps. The > > "index.tpl.cache.php" won't be needed for this "Advanced Caching > > Mechanism". The final outputted file is a normal .tpl.php file which > > will be included by Smarty to get executed. > > > > index.ppl.php <-- "p" stands for "pre" ;-) > > -------------- > > <?php smarty_function_foo("blah"); ?> > > {foobar bar="blah"} > > > > index.tpl.php > > ------------- > > This is output from function foo > > <?php smarty_function_foobar("blah"); ?> > > > > This should be easier to implement. To recognize if a Smarty tag should > > be cached I would prefer two ways: > > 1) Non-Cached functions > > - developer registers a function as non-cached > > - if compiler parses over a non-cached function just leave the tag > > alone. > > 2) Non-Cached variables > > - developer assigns a variable as non-cached to the template > > - if compiler parses over a function using a non-cached variable just > > leave the whole tag alone again. > > > > - {insert} should always be a non-cached function (current behaviour of > > Smarty) > > - {include} shouldn't be cached by default (otherwise it could lead in > > errors hard to track down). But the included template can use just the > > same mechanism as described above. So the included template is > > cached in it's own file. > > - I wouldn't use a {foo nocache=true} functionality because on the one > > hand this will be harder for the compiler to detect. On the other hand > > the designed shouldn't need to deside if the template should get > > cached or not. He can but he shouldn't need to :-) > > > > André > > > > > > > > "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag > > news:1045600811.23551.118.camel@lena.ispi.prv... > > > Yep, there are a few things that have been discussed. Here's another > > > similar one. > > > > > > We currently have three files: > > > > > > 1) the original template > > > 2) compiled template > > > 3) cached output of the template(s) > > > > > > #3 is a text file that is scanned for insert tags (if there are any). > > > Maybe this can change to a PHP script that is interpreted by PHP, and > > > imbed PHP tags where uncached data should be. So for example, some > > > pseudo-code... foo is cached, foobar is not: > > > > > > index.tpl > > > --------- > > > > > > {foo bar="blah"} > > > {foobar bar="blah"} > > > > > > > > > index.tpl.php > > > ------------- > > > > > > <?php smarty_function_foo("blah"); ?> > > > <?php smarty_function_foobar("blah"); ?> > > > > > > > > > index.tpl.cache.php > > > ------------------- > > > > > > This is output from function foo > > > <?php smarty_function_foobar("blah"); ?> > > > > > > > > > There are some things to get through, such as how to recognize the > > > cached and non-cached elements of index.tpl.php, and how to handle > > > multiple templates included within each other in the cache files (if > > > there are several templates included in a non-cached block, do they > > > still all go in the same cache file?) > > > > > > Monte > > > > > > On Tue, 2003-02-18 at 04:34, André Rabold wrote: > > > > Hi, > > > > > > > > I just thought about how to implement a {nocache}{/nocache} block > > > > function and I had an idea ... This could also help for more advanced > > > > caching algorithms like caching of single functions or caching of > > variables. > > > > > > > > The caching could work the following way: > > > > http://cmsng.sourceforge.net/TemplateCaching.png > > > > > > > > - The blue path is the default behaviour of Smarty if caching is > > disabled. > > > > This works like in the current version. > > > > > > > > Here's the difference between a not compiled template, a precompiled and > > > > a compiled one: > > > > (The foo function is cached. The bar function is not. How to distiguish > > if a > > > > function > > > > or variable or what ever should be cached or not is not part of this > > > > discussion ;-) > > > > > > > > --- not compiled --- > > > > {foo blah="blub"} > > > > {bar blah="blub"} > > > > > > > > --- precompiled --- > > > > <?php echo $this->plugins["foo"] ... ?> > > > > {bar blah="blub"} > > > > > > > > --- compiled --- > > > > <?php echo $this->plugins["foo"] ... ?> > > > > <?php echo $this->plugins["bar"] ... ?> > > > > > > > > The trick is that we now have two compiled template types. The first > > > > (precompiled) one contains all the compiled syntax (PHP code) of Smarty > > > > functions that should be cached. But there are still some Smarty tags > > left > > > > in the code. This tags are called non-cached. > > > > If the cache is cleared Smarty executed this template. The result is > > another > > > > Template full of html code and still these non-cached Smarty tags. This > > > > template is called "pre-cached" because there is no php code left in the > > > > template but the non-cached Smarty tags. > > > > > > > > The second compilation step takes as input the pre-cached template > > instead > > > > of the completely non-compiled one. The output is a compiled template > > > > in which only the non-cached functions are php code. The cached ones are > > > > already there as html code. > > > > > > > > Now Smarty can just uses this second compiled template just like a > > normal > > > > one. > > > > > > > > The advantage of this method is that you can use nearly all of your > > existing > > > > code without any rewrites. The compiler just needs a parameter if it's > > the > > > > first ("pre-compiled") or second ("compiled") compile step. > > > > And it needs > > to > > > > distinguish between cached and non-cached functions. If it's in first > > > > compile > > > > step and a non-cached function is detected just leave it alone - don't > > > > modify > > > > it yet. If the compiler is in the second step just compile everything. > > > > > > > > The disadvantage is a performance loss if a cached template needs to be > > > > rebuild: > > > > - first get the "pre-compiled" template and execute it > > > > - compile the recently executed template again and execute again > > > > - now output the content > > > > You need to compile the template again which is slow. But normally there > > > > shouldn't be a lot of Smarty tags left in the pre-compiled template. > > > > Otherwise > > > > caching wouldn't make a sense at all. > > > > > > > > Any ideas? > > > > André > > > -- > > > Monte Ohrt <monte@ispi.net> > > > > -- > Monte Ohrt <monte@ispi.net> >

« previous php.smarty.dev (#738) next »