Re: [SMARTY-DEV] First step tosolve {nocache} {/nocache}problematic
| From: | Andr� Rabold | 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>
>