Re: [SMARTY-DEV] Bringing the {insert} functionality to other tags
| From: | Monte Ohrt | Date: | Wed, 04 Sep 2002 20:39:28 +0000 |
| Subject: | Re: [SMARTY-DEV] Bringing the {insert} functionality to other tags | ||
| References: | 1 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-256@lists.php.net to get a copy of this message | ||
This would be kind of a template-tag-based approach instead of a function-based approach, so you would end up putting stuff like this in the template:
{cache}
...
{/cache}
or
{nocache}
...
{/nocache}
or possibly:
{include file="poll.tpl" cache=true}
The issues I see with this approach:
1) designers are now confronted with cache tags, which means they must be now aware of what is cached and what that means. I liked the idea of leaving the caching out of the templates, making them look the same whether elements are cached or not and letting the application decide what gets cached. Designers shouldn't care what is cached, or be concerned what they put inside and outside of the tags.
2) If you want to debug or change what gets cached, you have to wade through your template files to find and make changes, possibly breaking the design of your template with errors. This kind of defeats some of the purpose of the template engine: separating presentation from application logic. I think the caching would be part of the app logic, wouldn't you?
3) Not so significant problem, but this is a much bigger undertaking than registration based caching.
Maybe another idea is to register _templates_ that get cached instead of functions (or both?) Then when you fetch(), display() or {include ...} a template, the registered template (and child templates) contents get cached (or not cached). So instead of:
cached data
{nocache}
not cached data
{/nocache}
cached data
you would have instead:
index.php
---------
$this->caching = true;
$this->register_nocache_template('foo.tpl');
$this->display('index.tpl');
index.tpl
---------
cached data
{include file="foo.tpl"}
cached data
foo.tpl
-------
not cached data
and the output of the include does not get cached. Or the other way around, nothing gets cached except the templates specifically marked to be cached.
I see the merits of having tags in the templates that control caching, I'm just outlining my first concerns. My gut instinct says no, this isn't nearly as managable. Keep the templates clean and simple, don't clutter them with cache constructs. Let the application handle that.
Monte
G wrote:
If I understand correctly, the functions would just return text. What I don't like about this approach is that they don't use templates. Maybe add a template param. I really like this approach though: template: cache this.... {no_cache} date :{$smarty.now} {/no_cache} more cached ... ------------ Everything in one template. Gerard I'm not for certain how it will be done, I myself haven't had a whole lot of time to devote to it lately. First I'd like to see some things cleaned up in the engine. Break apart the functionality of the "rendering pipeline" so each piece is clearly defined. At the moment a lot of things are clumped together in the display() function which I'd like to see organized a bit better. Method calls come with a slight cost, so of course things must be weighed/tested/tuned. This may lead to things like putting the caching/compiling functionality into plugins, simplifying the core engine and making it easy to drop in other functionality. Anyways, on to caching. I have had very little thought on how caching would work, so I'll try it now :-) One idea (and probably most workable) is to cache on a function-basis. Two methods come to mind, either you cache nothing and register which functions get cached, or cache everything and register which functions _don't_ get cached (currently how {insert} works). Either way, no cache markup is necessary in the templates. If you want a particular function cached/uncached, you register/unregister it. This way all existing templates can support new caching methods without modification. Also the template functions should not require caching support, they should work without modification. This keeps the caching in an isolated layer in the template engine as well. Ok some ideas how this might work. Those of you finding these examples in the mailing list archives, Don't send e-mail telling me you cut-n-paste and they don't work. ;-) example: $this->caching = true; $this->register_cache_function('get_poll'); or: $this->caching = false; $this->register_nocache_function('get_poll'); // ??? Then the output of this template function would get cached (or not cached): {get_poll id=2} Maybe an optional second parameter designates the lifetime: register_cache_function('get_poll',300); How to handle the concept of "cache none except these functions" and "cache all except these functions" ? I'm not sure if we should support one or both. If both, do we use different function names, or parameter values, or ? This will probably take some experimenting. Of course there are functions that wouldn't make sense to cache, and presumably numerous other issues to think through. Monte Ivo Jansch wrote:-- Monte Ohrt <monte@ispi.net> Director of Technology, ispi Inc.Hi, a reply to a mail from a few weeks back... Monte Ohrt wrote:I think one of the next major feature changes in Smarty is updating the caching mechanism, so now is a good time to discuss it. I like the idea of having the programmers decide which functions are not cached, as opposed to using tags in the templates.What are your current ideas towards implementing this? Do you already know how you're going to do it? Greetings, Ivo