RE: [SMARTY-DEV] Bringing the {insert} functionality to other tags

Valid points, but it'd sort of be {include} vs. {no_cache}, and template designers would still need to be somewhat concerned with caching. Plus {include} would fragment the templates. I have some templates that would end up getting split up into 4-5 different files. How about caching variables? The templates would be exactly the same, but your code would be something like: $smarty->nocache_vars(array( 'cookies' => 'get_cookies', 'ip' => 'get_ip' )); where the second argument would be the function name for retrieving that variable? I guess the functions would need to be put in plugins/? Think I like this idea :). Another idea I had is work no_cache into block functions. Haven't use them yet though, so I'm not familiar with how that'd work. Gerard > -----Original Message----- > From: Monte Ohrt [mailto:monte@ispi.net] > Sent: Wednesday, September 04, 2002 2:39 PM > To: G > Cc: smarty-dev@lists.php.net > Subject: Re: [SMARTY-DEV] Bringing the {insert} functionality to other > tags > > > 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: > > > >>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 > >> > > > > > > > > > > -- > Monte Ohrt <monte@ispi.net> > Director of Technology, ispi Inc. > >