Re: [SMARTY-DEV] Once again: Solution for {nocache} blockfunction?!
| From: | Andr� Rabold | Date: | Wed, 19 Feb 2003 15:46:34 +0000 |
| Subject: | Re: [SMARTY-DEV] Once again: Solution for {nocache} blockfunction?! | ||
| References: | 1 2 3 4 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-738@lists.php.net to get a copy of this message | ||
Hi Monte
> {SMARTY_PRECOMPILE_TAG cacheme foo="blah" SMARTY_PRECOMPILE_TAG}
> {include file="foo.tpl"}
Sure something like this is needed. Just wanted to keep my examples simple
;-)
> I don't see how your method is any different than mine... except calling
> "precompiled/compiled" vs. "compiled/cached"
The difference is only small. But as far as I have understood you just
include (I mean the
PHP function) the compiled file.
Then the complete output is stored in the .cache file. This .cache file is
finally displayed.
I have just extended this functionality so the .tpl still contains Smarty
tags and
gets compiled again instead of just included. (This is why I called it
precompiled in my
examples to show there's a difference between normal .tpl files). The
resulting file is
the .tpl after all. Include it (again the PHP function is meant) and the
output is html
with cached and non-cached parts.
This is why I like this idea. It would be easier to implement than
everything other I've heard
or read about so far. Don't you think this could solve the non-cached blocks
and
functions problematic?
Btw: I thought I post my ideas here not because I have a solution or an
impression of what
the result will be. I just thought about a way to _implement_ it. This is
why I created
the diagramm. (http://cmsng.sourceforge.net/TemplateCaching.png). It helped
me to
understand the problematic. I have created it for Smarty (not for any other
system).
Perhaps it's not a good idea but how would you implement your method?
bye,
André
"Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag
news:1045666228.28271.17.camel@lena.ispi.prv...
> One problem I see is the syntax of the precompiled template tags, they
> can get mixed up with output.
>
> example:
>
> index.tpl
> ---------
>
> {echo text="this is a test"}
> {cacheme foo="blah"}
> {ldelim}include file="foo.tpl"{rdelim}
>
> index.ppl.php
> -------------
> <?php echo "this is a test" ?>
> {cacheme foo="blah"}
> {include file="foo.tpl"}
>
>
> oops, now that literal tag is going to get parsed, not good!
>
> That is why the Smarty md5 string is used in the current cache files, to
> be sure the insert tags are not part of the output.
>
> Therefore, maybe the precompiled files should have tags like:
>
> index.ppl.php
> -------------
> <?php echo "this is a test" ?>
> {SMARTY_PRECOMPILE_TAG cacheme foo="blah" SMARTY_PRECOMPILE_TAG}
> {include file="foo.tpl"}
>
>
> I don't see how your method is any different than mine... except calling
> "precompiled/compiled" vs. "compiled/cached"
>
> Monte
>
>
> On Wed, 2003-02-19 at 02:59, André Rabold wrote:
> > Thanks for answering :-)
> >
> > > index.tpl.php
> > > -------------
> > >
> > > <?php smarty_function_foo("blah"); ?>
> > > <?php smarty_function_foobar("blah"); ?>
> > >
> > > There are some things to get through, such as how to recognize the
> > > cached and non-cached elements of index.tpl.php, and how to handle
> > > multiple templates included within each other in the cache files (if
> > > there are several templates included in a non-cached block, do they
> > > still all go in the same cache file?)
> > >
> >
> > This is the reason why I would prefer two compiling steps. The
> > "index.tpl.cache.php" won't be needed for this "Advanced Caching
> > Mechanism". The final outputted file is a normal .tpl.php file which
> > will be included by Smarty to get executed.
> >
> > index.ppl.php <-- "p" stands for "pre" ;-)
> > --------------
> > <?php smarty_function_foo("blah"); ?>
> > {foobar bar="blah"}
> >
> > index.tpl.php
> > -------------
> > This is output from function foo
> > <?php smarty_function_foobar("blah"); ?>
> >
> > This should be easier to implement. To recognize if a Smarty tag should
> > be cached I would prefer two ways:
> > 1) Non-Cached functions
> > - developer registers a function as non-cached
> > - if compiler parses over a non-cached function just leave the tag
> > alone.
> > 2) Non-Cached variables
> > - developer assigns a variable as non-cached to the template
> > - if compiler parses over a function using a non-cached variable
just
> > leave the whole tag alone again.
> >
> > - {insert} should always be a non-cached function (current behaviour of
> > Smarty)
> > - {include} shouldn't be cached by default (otherwise it could lead in
> > errors hard to track down). But the included template can use just
the
> > same mechanism as described above. So the included template is
> > cached in it's own file.
> > - I wouldn't use a {foo nocache=true} functionality because on the one
> > hand this will be harder for the compiler to detect. On the other
hand
> > the designed shouldn't need to deside if the template should get
> > cached or not. He can but he shouldn't need to :-)
> >
> > André
> >
> >
> >
> > "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag
> > news:1045600811.23551.118.camel@lena.ispi.prv...
> > > Yep, there are a few things that have been discussed. Here's another
> > > similar one.
> > >
> > > We currently have three files:
> > >
> > > 1) the original template
> > > 2) compiled template
> > > 3) cached output of the template(s)
> > >
> > > #3 is a text file that is scanned for insert tags (if there are any).
> > > Maybe this can change to a PHP script that is interpreted by PHP, and
> > > imbed PHP tags where uncached data should be. So for example, some
> > > pseudo-code... foo is cached, foobar is not:
> > >
> > > index.tpl
> > > ---------
> > >
> > > {foo bar="blah"}
> > > {foobar bar="blah"}
> > >
> > >
> > > index.tpl.php
> > > -------------
> > >
> > > <?php smarty_function_foo("blah"); ?>
> > > <?php smarty_function_foobar("blah"); ?>
> > >
> > >
> > > index.tpl.cache.php
> > > -------------------
> > >
> > > This is output from function foo
> > > <?php smarty_function_foobar("blah"); ?>
> > >
> > >
> > > There are some things to get through, such as how to recognize the
> > > cached and non-cached elements of index.tpl.php, and how to handle
> > > multiple templates included within each other in the cache files (if
> > > there are several templates included in a non-cached block, do they
> > > still all go in the same cache file?)
> > >
> > > Monte
> > >
> > > On Tue, 2003-02-18 at 04:34, André Rabold wrote:
> > > > Hi,
> > > >
> > > > I just thought about how to implement a {nocache}{/nocache} block
> > > > function and I had an idea ... This could also help for more
advanced
> > > > caching algorithms like caching of single functions or caching of
> > variables.
> > > >
> > > > The caching could work the following way:
> > > > http://cmsng.sourceforge.net/TemplateCaching.png
> > > >
> > > > - The blue path is the default behaviour of Smarty if caching is
> > disabled.
> > > > This works like in the current version.
> > > >
> > > > Here's the difference between a not compiled template, a precompiled
and
> > > > a compiled one:
> > > > (The foo function is cached. The bar function is not. How to
distiguish
> > if a
> > > > function
> > > > or variable or what ever should be cached or not is not part of this
> > > > discussion ;-)
> > > >
> > > > --- not compiled ---
> > > > {foo blah="blub"}
> > > > {bar blah="blub"}
> > > >
> > > > --- precompiled ---
> > > > <?php echo $this->plugins["foo"] ... ?>
> > > > {bar blah="blub"}
> > > >
> > > > --- compiled ---
> > > > <?php echo $this->plugins["foo"] ... ?>
> > > > <?php echo $this->plugins["bar"] ... ?>
> > > >
> > > > The trick is that we now have two compiled template types. The first
> > > > (precompiled) one contains all the compiled syntax (PHP code) of
Smarty
> > > > functions that should be cached. But there are still some Smarty
tags
> > left
> > > > in the code. This tags are called non-cached.
> > > > If the cache is cleared Smarty executed this template. The result is
> > another
> > > > Template full of html code and still these non-cached Smarty tags.
This
> > > > template is called "pre-cached" because there is no php code left in
the
> > > > template but the non-cached Smarty tags.
> > > >
> > > > The second compilation step takes as input the pre-cached template
> > instead
> > > > of the completely non-compiled one. The output is a compiled
template
> > > > in which only the non-cached functions are php code. The cached ones
are
> > > > already there as html code.
> > > >
> > > > Now Smarty can just uses this second compiled template just like a
> > normal
> > > > one.
> > > >
> > > > The advantage of this method is that you can use nearly all of your
> > existing
> > > > code without any rewrites. The compiler just needs a parameter if
it's
> > the
> > > > first ("pre-compiled") or second ("compiled") compile step.
> > > > And it
needs
> > to
> > > > distinguish between cached and non-cached functions. If it's in
first
> > > > compile
> > > > step and a non-cached function is detected just leave it alone -
don't
> > > > modify
> > > > it yet. If the compiler is in the second step just compile
everything.
> > > >
> > > > The disadvantage is a performance loss if a cached template needs to
be
> > > > rebuild:
> > > > - first get the "pre-compiled" template and execute it
> > > > - compile the recently executed template again and execute again
> > > > - now output the content
> > > > You need to compile the template again which is slow. But normally
there
> > > > shouldn't be a lot of Smarty tags left in the pre-compiled template.
> > > > Otherwise
> > > > caching wouldn't make a sense at all.
> > > >
> > > > Any ideas?
> > > > André
> > > --
> > > Monte Ohrt <monte@ispi.net>
> > >
> --
> Monte Ohrt <monte@ispi.net>
>