Re: [SMARTY-DEV] First step tosolve {nocache} {/nocache}problematic

From: Date: Mon, 27 Jan 2003 10:21:26 +0000
Subject: Re: [SMARTY-DEV] First step tosolve {nocache} {/nocache}problematic
References: 1 2 3 4 5 6 7 8  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-629@lists.php.net to get a copy of this message
Regarding the use of a "nocache=true" parameter: Here's a simple example: The {section} tag. Should a section be cached or not? {* $bar is set to cache *} {$bar|@count} entries: {section name="foo" loop=$bar nocache=true} {$bar[foo]} {/section} --> POSSIBLY UNEXPECTED RESULTS {* $bar is set to no-cache *} {$bar|@count} entries: {section name="foo" loop=$bar} {$bar[foo]} {/section} --> POSSIBLY UNEXPECTED RESULTS {* $bar is set to no-cache *} {$bar|@count} entries: {section name="foo" loop=$bar nocache=true} {$bar[foo]} {/section} --> RIGHT RESULTS It is really complicated to use no-cached variables for the template designer because he whould have to know whether a variable is cached or not. So I think a function should not be cached if it is using a non-cached variable. Otherwise it will get complicated for the designer. If the programmer desides to change the caching behaviour of a variable he would have to call the designer to change the templates ?!?!! > Some more things to think about: if a variable is passed to an included > template, does it inherit the caching behavior? Same with vars that get > assigned to another var name. Including templates combined with caching gets cruel. That's the reason why I would change the behaviour of the {include} tag a bit: Included templates use the same variable scope as the parent one, don't they? That is not a really good programming technique I think. A included template could easily destroy the parent's variables. Includes should work like a subfunction call. So you have to manually set the parameters the included template should be able to use. If you want to use the same scope you have to set a special parameter. And in this case the include get's (never?) cached. Otherwise the caching depends on the given parameters like if using a normal function. Thoughts? André "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag news:1043357695.4488.101.camel@lena.ispi.prv... > On Thu, 2003-01-23 at 10:05, Ivo Jansch wrote: > > Hi, > > > > Monte Ohrt wrote: > > > > > {$canedit} > > > {myFunc foo=$canedit} > > > {if $canedit ne "false"} > > > ... > > > {/if} > > > The first one is not cached, whereas the second one is not affected by > > > the cache setting, the output of myFunc still gets cached. Same with the > > > if statement. > > > > Well, if you want to do it right, those statements should not be cached > > either. The $canedit is not cachable for a reason, probably that it > > changes a lot. So if {$canedit} changes, you'd expect {myFunc > > foo=$canedit} to be changed too (because apparantly its output is > > dependent on $canedit, which has just changes). > > > > This is probably a difficult thing to do. The fact that something can be > > cached is dependent on its own setting + the settings of all variables > > it depends on. If any of the 'components' of a tag or statement may not > > be cached, than the entire statement may not be cached. > > Some more things to think about: if a variable is passed to an included > template, does it inherit the caching behavior? Same with vars that get > assigned to another var name. > > I'm not so sure about the function caching. I would think a function's > cache behavior should be controlled by its registration, not by the > variables that it takes as parameters. If you don't want a function > cached, be sure to register it that way. You will know ahead of time > what vars will be passed anyways. That could really get nasty trying to > resolve if all the parameters passed are cached or not, and it could > make debugging a chore too. > > > > > Compare with an insert statement. It's not cached even if it is called > > from inside a template that itself is cached. > > insert is just a function that is always registered as not cachable. > > > As far as how caching will work under the covers, first thoughts are > that the files under /cache/ will be identical to the files in > /templates_c/ except that the cached parts will contain the output > instead of the PHP code needed to create them. That means cached files > are interpreted, and therefore acceleratable. > > example (semi-psuedo code): > > index.tpl (original template) > ----------------------------- > > TEST {$myname} > TEST {$myname_nc} {* registered not cached *} > {foo p1="bar"} > {foo_nc p1="bar"} {* registered not cached *} > {nocache} > TEST {$myname} > {/nocache} > > > index.tpl.php (compiled template) > --------------------------------- > > TEST <?php echo $myname; ?> > TEST <?php echo $myname_nc; ?> > <?php echo foo($p1); ?> > <?php echo foo_nc($p1); ?> > TEST <?php echo $myname; ?> > > > index.tpl.cache.php (cached template) > ------------------------------------- > > TEST Bob Smith > TEST <?php echo $myname_nc; ?> > OUTPUT OF FOO > <?php echo foo_nc($p1); ?> > TEST <?php echo $myname; ?> > > > > > > -- > Monte Ohrt <monte@ispi.net> >

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