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

On Wed, 2003-01-22 at 10:26, André Rabold wrote: > Yeah, that's right, Monte. > > > Does the designer care what portions of a template are > > cached or not cached? > > Doesn't the designer already have this possibility? He > must know what the {insert} function is for or he won't use it at > all. So he always need to know if his template will be cached > and what portions shouldn't be cached. Am I wrong? > Btw: I'm not using caching at all for now... ;-) example: {insert name="banner" id=$banner_id} The designer would know that that this produces a banner, maybe by the name, but definately by observing that on the rendered page. Whether or not it is cached is not immediately obvious nor a concern. > > I have an example why {nocache} could be very useful: > > I have a template showing a table. In each row another data > record is shown. Behind each row there are three buttons: > view / edit / delete. Depending on the current access level > I want to display or hide one or all of these buttons. E.g.: > {if $canEdit} > <a href="...">edit</a> > {/if} > All of the content can and should be cached for performance > reasons. But not the three buttons behind each line. I could > use different cache ids for different access levels but in this > case very very much cached templates would be created :-( > So a {nocache}{/nocache} function surrounding the above > code would be a good solution in my eyes. > > 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? > > > Should cached portions of a page be included, > > imbedded or both? > > I'm not sure what you mean?! imbedded: {nocache} foo bar foo bar foo bar foo bar {/nocache} included: {include file="foo.tpl" cached=no} (or possibly register template files as cached/nocached then no need for the cached parameter) > > > Maybe it would be helpful to designate custom > > functions as cached or non-cached at registration time, so {myFunc > > foo="bar"} may or may not get cached depending on how it was registered. > > This sounds quite useful. If the programmer desides if a function can be > cached > or not the designer doesn't need to deside anymore. > > But then also a block function which won't be cached would be one of the > first requests. This won't be possible easily because of the question if all > included function of the block plugin should should be cached or not: > {myNocachedBlockFunction} > {* should this be cached or not ??? *} > {/myNocachedBlockFunction} > > If the content of the block function is NOT cached then it would be the same > as the idea of a {nocache}{/nocache} block. Exactly. If you could register a block function as cached or not, then {nocache}{/nocache} could just be a block function registered as "not cached" that does nothing but keep the contents from being cached. We may end up with embedded cache tags in templates, I haven't done any extensive tests. But IMHO, I think this is mixing application logic with the templates. The designer should be able to focus on template design and not worry about what part is cached and what is not, or possibly screwing things up by accidentally deleting or moving cache tags. Monte