[prev in list] [next in list] [prev in thread] [next in thread] 

List:       smarty-dev
Subject:    Re: [SMARTY-DEV] First step to solve
From:       Monte Ohrt <monte () ispi ! net>
Date:       2003-01-23 14:42:17
[Download RAW message or body]


On Thu, 2003-01-23 at 01:34, Ivo Jansch wrote:
> Hi,
> 
> Monte Ohrt wrote:
> 
> >>If the designed shouldn't care / is not allowed to care about
> >>caching, how would a good solution look like? I have already
> >>thought about using {insert} tags but I'm not quite happy with
> >>it. Perhaps anyone has an idea?
> 
> In the discussion several months ago, we'd come to an understanding 
> where the programmer should be able to influence what tags should be 
> cached and which shouldn't. So this should be implemented on the plugin 
> level.
> 
> But there are 2 things you can use in a template. Tags (plugins, 
> functions, etc) and Variables. So maybe for variables it could be 
> decided when assigning them?
> 
> The programmer would for example do something like:
> 
> $smarty->assign("canedit", $canEditValue, false);
> 
> Here false is indicating that this variable may not be cached, so all 
> statements using this variable (if statements, tags with this param as 
> parameter etc) should be rendered at the last stage of the multistage 
> renderer (if you can still remember the discussion about generic 
> multistage rendering)

Sounds like a good idea. I assume that this only affects a directly
displayed variable, and not one used in a function. Example, lets say we
have $canedit registered as uncachable:

{$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.

Monte


-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]