Re: [SMARTY-DEV] Once again: Solution for {nocache} block function?!
| From: | Monte Ohrt | Date: | Wed, 19 Feb 2003 14:50:29 +0000 |
| Subject: | Re: [SMARTY-DEV] Once again: Solution for {nocache} block function?! | ||
| References: | 1 2 3 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-733@lists.php.net to get a copy of this message | ||
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>