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

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> >