Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.

{nocache} Patch
Goto page Previous  1, 2
 
Post new topic   Reply to topic    Smarty Forum Index -> Smarty Development
View previous topic :: View next topic  
Author Message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 4:08 pm    Post subject: Reply with quote

Monte: can't wait to see how it develops.

Andre:
Quote:
An idea I just had and I'm not sure if it would be practical but what if I just replace the not-cached code within a cache file with pure PHP tags so the cached file gets just included if displayed?!


I was going to suggest something like this. This is similar to what I did to get templated config files. Wouldn't you just need to save the compiled file to the cache? Then you use force_compile to get a fresh cache. Its hacky though.

Quote:
Then I wouldn't need another file. Would this break something? I have to think about it ... Rolling Eyes


I think you would have to ensure that your non-cached code portions that ended up living in cache files had cache_id's different than the calling template. Either that or a different compile_id?

I thought it would be interesting if the last parameter in your register_function (true/false) also allowed an optional associative array of cache_name->ttl's. Right now, if you pass true, you get page level caching of the tag. If you pass false, you get insert-type functionality or as per your example, a form of tag level caching of the object. If an array is passed, you'd get the latter in a slightly automated form with the array being used to set up named caches with different ttls.

Just a thought.

I'm installing the patch right now! Finally!
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Tue Apr 29, 2003 4:55 pm    Post subject: Reply with quote

monte: PLEASE give us something like {nocache}-blocks, too. It's often that I couldn't do something with a non-cached function, because it's not always exactly the same thing I want to put out or whatever... see my posting above on this for a little example... always throwing the non-cached parts into extra templates and then let these templates be returned by non-cached functions doesn't make sense, I may well use inserts for that, too
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 5:55 pm    Post subject: Reply with quote

One thing that I like about this patch is that it allows non-cached block functions which is not at possible in the current Smarty, even with insert-type syntax.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7366
Location: Lincoln Nebraska, USA

PostPosted: Tue Apr 29, 2003 6:51 pm    Post subject: Reply with quote

A {nocache}{/nocache} block would simply be a block function registered as non-cached.

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 7:02 pm    Post subject: Reply with quote

mohrt wrote:
A {nocache}{/nocache} block would simply be a block function registered as non-cached.


Exactly! That's what I like! (because now any PHP function can now be used in a non-cached block).

Off-topic: Is there a performance hit when using block functions compared to non block functions?
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Tue Apr 29, 2003 7:38 pm    Post subject: Reply with quote

D'Oh, forgive me, Monte, I should use my own brain more often Wink
Back to top
View user's profile Send private message
andre
Smarty Pro


Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany

PostPosted: Tue Apr 29, 2003 8:18 pm    Post subject: Reply with quote

boots wrote:
I think you would have to ensure that your non-cached code portions that ended up living in cache files had cache_id's different than the calling template. Either that or a different compile_id?


Think you misunderstood me ... I won't change the current cache behaviour. But now (without my patch) a {insert} function ist compiled and cached as {SOMETHINGUNIQUE...serialized_array...SOMETHINGUNIQUE}

At runtime this is replaced via pregex with the result of a function call taking the serialized array as parameter.

So why don't we change {SOMETHINGUNIQUE...} to <?php ... ?> and call the function directly?! So we would just need to include the cached template to get it executed. This is what I wanted to do. Instead of <!--{#SMARTYCACHE# ... }--> write the PHP code directly in the appropriate cache file.

... sorry... need to go NOW... I'm posting this entry unread (!!!) ... so don't blame me Wink Bye
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Tue Apr 29, 2003 9:15 pm    Post subject: Reply with quote

I guess this is the best idea - just write the PHP code to the cache. {insert}s are sloooooooooooooooow Smile
Back to top
View user's profile Send private message
andre
Smarty Pro


Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany

PostPosted: Tue Apr 29, 2003 9:19 pm    Post subject: Reply with quote

Soo... back again Smile

The only problem I see with the above two posting is the following:

Cache files can be stored everywhere. It depends on your cache file handler. So including with include() function is not always possible. So this raises another question:

1) Templates can be loaded from anywhere (because they don't need to be included)
2) Compiled templates needs to resist in the file system (because they get included)
3) Cached templates can resist anywhere again

I think a upcoming Smarty version will also allow compiled templates to be stored anywhere. So question to Monte / Messju: Is this planned? If yes, how do you think you can implement this? So how do you "include" the compiled template if its located in a DB for example?
Exactly this (yet unknown) way I would prefer for including the cached templates with PHP in them. I know the idea Messju (Monte?) had about separating the executable code from the cached template and store it in a separate file. This way the separated code can be easily included again which gives performance. BUT WHAT if you don't want Smarty to create files in your filesystem? If you want it to store EVERYTHING within your database?

So perhaps we could create a Smarty method here to execute the script code located in a string (e.g. a file on your hard drive or a string stored within a DB). This method should be so flexible it can execute a code on your harddrive by including it (use "include()" function) or to eval() it if it comes from another source. This way the execution / inclusion of a source (say template, compiled template or cached template) is fully transparent to the Smarty class.

Back to the point of discussion Wink :
If you store your cached templates onto your file system it will be included by "include()" which is fast and is even more accelerated by PHPAccelerator. If your cached templates lie outside of your file system into a database for example the output gets evaled with "eval()" which is quite slow compared to the first method.

Hope you understand what I wanted to say. Please ignore the typos because I'm drunk at the moment Embarassed but most people say I am most productive if I am drunk Wink (it's 11 p.m here Wink )
Back to top
View user's profile Send private message
andre
Smarty Pro


Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany

PostPosted: Tue Apr 29, 2003 9:29 pm    Post subject: Reply with quote

Short addition and idea:

1) Remove all cache file handling from Smarty
2) Create a separate cache handling class which is included in Smarty package which is nothing more than a "custom" (but standardized) cache handler function
3) Like custom resource types these custom cache handlers do everything Smarty needs. So there need to be methods for getting cache creation time, methods to retrieve cache infos like lifetime etc., a method to get the cached content, etc. (Everything the current custom cache handlers need to do too already)
4) Add a new method: execute() which evals the code of the cache. For the standard cache handler this is a simple include(). For a cache handler which is using DB access this will be a eval() perhaps.

So it would be even more transparent to Smarty. I saw that the default cache handling is hardcoded within the Smarty class. Changing this could perhaps solve the problems?!

____
Now it's time for TV ... 'till tomorrow Wink
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7366
Location: Lincoln Nebraska, USA

PostPosted: Tue Apr 29, 2003 10:13 pm    Post subject: Reply with quote

Yes, abstracting the cache handling from Smarty into a plugin is the right idea. This goes back to the rendering "pipeline" that has been discussed in the mailing lists in the past. This will require some fundamental changes to the engine (such as cache files being included() instead of interpreted), but all in all will make the core even tighter and more flexible. There is more than just caching that can be abstracted too.

The tricky part is getting abstraction without an added overhead (basically dealing with wrappered function calls). The main obstacle is you cannot add methods to an already instantiated object. Look at how the compiler is abstracted, this is basically a hack but it works, it gets the compiling code out of the main object and reduces its size by more than half. When PHP5 rolls around that might be different, but until that can be required (long way off), we make use of what we've got.

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 10:53 pm    Post subject: Reply with quote

Ramblings:

Quote:
Yes, abstracting the cache handling from Smarty into a plugin is the right idea

+10

Quote:
The tricky part is getting abstraction without an added overhead (basically dealing with wrappered function calls). The main obstacle is you cannot add methods to an already instantiated object.

Wouldn't a decorator work for that?

Quote:
I saw that the default cache handling is hardcoded within the Smarty class

d'oh. Cache handling is tied too tightly. Smarty parts are still very tightly bound to each other.

Quote:
There is more than just caching that can be abstracted too.

Yum!

Quote:
2) Compiled templates needs to resist in the file system (because they get included)

Not completely true. Perhaps earlier, but PHP 4.3+ internally uses streams for all io so you can read from any registered PHP stream resource. Thus I can do:

Code:
include "http://mysite/myfile.php";


Again, any registered stream handler will work so you can write a db stream handler if you want. This was part of the motivation for the discussion on userland streams and smarty resources in http://www.phpinsider.com/smarty-forum/viewtopic.php?t=6 : (summary: user streams are too young to do anything significant at this point)

One thing that I've been hoping to see is the file handling facilities moved out of the core and into a resource. Unfortunately, that would require a read/write api for resources and perhaps a few extra considerations.

As for pipelines, any plans for a request handler and a template-object/class auto mapping facility?

2c.
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 11:03 pm    Post subject: Reply with quote

On caches:

One thing I find confusing is talking about "cache" directory and "compile" directory. They are both file caches, they just contain different data and within smarty have different precedences and rebuilding rules. But to a cache handler, they should be the same animal (the rules can be plugged via a driver, I bet). I almost wish the names were "compile cache" and "output cache".

A single orderly interface to deal with caches would be neat. Especially if it allowed n-cache types and allowed sharing of id's across types. That way other libraries that use caches can be managed by the single class and can have its cache data group tagged with smarty cache data.

Sorry if I am repeating old discussions that I am unaware of or saying to many obvious things--kinda why I was looking for a roadmap Smile

4c.
Back to top
View user's profile Send private message
messju
Administrator


Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany

PostPosted: Tue Apr 29, 2003 11:09 pm    Post subject: Reply with quote

sorry, i'm really busy here. i won't be able to get hands on this till the weekend, i'm afraid.

anyway: i like the idea of taking the cache-handling out of the core, though it won't be easy. personally, i don't like the idea of taking the compiled templates out of the filesystem and i am also not attracted by the idea of emitting the php-code directly in the cached template. but that's just my superficial feeling at the moment, so not problematic at all.

i have also some code which i didn't touch for a few weeks (just cvs upd to keep it in sync with head). AFAIR it has some similarities to andre's approach like the nocache parameter. btw: i'd vote for calling the parameter $cacheable instead of $cached. (just a thought)

i have done different versions (all buggy of course) all around the same core changes in the compiler. one version uses eval to evaluate the non-cached parts. one version generates a cache-file that is a valid includable php-file, like the compiled template and one version writes a second php-file next to the compiled-tpl, that contains the non-cached parts as function-definitions.
the last one should be able to share the functions of one compile-id by all it's associated cache_ids, it's the one i like most, although it implies a third file in addition to compiled-tpl and cached-tpl and maybe the additional logic eats up the good idea.

i am eager to benchmark these and andre's one to get a feeling, how the different approaches behave performance-wise. till now i only tested if they produce reasonable output at all Smile i know there won't be no optimal solution. some approach may be better with a lot of non-cached parts, another may be better used with a few bigger non-cached parts etc.
but i think it is important to become a slight idea how much (and in which) direction they differ.

andre: if you have testcode for your non-cached function you wish to share, tell me.

i have to get busy now...

greetings
messju
Back to top
View user's profile Send private message Send e-mail Visit poster's website
andre
Smarty Pro


Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany

PostPosted: Wed Apr 30, 2003 7:35 am    Post subject: Reply with quote

Quote:
i'd vote for calling the parameter $cacheable instead of $cached. (just a thought)

I'm bad in finding good function and variable names. Thanks Smile

Quote:
i am eager to benchmark these and andre's one to get a feeling, how the different approaches behave performance-wise. till now i only tested if they produce reasonable output at all i know there won't be no optimal solution. some approach may be better with a lot of non-cached parts, another may be better used with a few bigger non-cached parts etc.
but i think it is important to become a slight idea how much (and in which) direction they differ.


This would be very interessting. Too bad I cannot sent you the calendar application I wrote because it's part of a bigger project and cannot be run standalone. I speed it up from 7-8 seconds loading time to 1,3-5 seconds using my nocache-patch. At least 0,5 - 0,8 seconds are spend for blocks around the calendar which aren't cached nor optimized yet so you can substract it.
It mainly consists of a section which look through all days of a month. A second nested section loops through all dates of the currently processed day of month. For each date I use two includes: First generates the output displayed within the calendar: "André in Meeting". The second generates a popup hint using Overlib displaying more detailed informations: "Concerned Users: André, Messju, Monte, boots Wink \n 10:00 am - 11:00 am \n Meeting \n We are meeting to discuss about Smarty".
The nocache part is used to display a "add" button for each day of month in the calendar and a menu at the top where a user can add an entry, request vacations and call other needed functions.

Perhaps you can test the performance using such a model because (nested) sections containing includes are very slow in Smarty if you don't use caching. It look something like this: (But a bit more complex)

Code:
{* Calendar Template *}
<table>
{section loop=$days name="i"}
  {if $smarty.section.i mod 7 == 0}
     {if $smarty.section.i.index_last > 0}
        </tr>
     {elseif $smarty.section.i.index > 0}
        </tr><tr>
     {else}
        <tr>
     {/if}
  {/if}
  <td>
    <table width="100%" border="0">
      <tr>
         <th>{$days[i].date|date_format:"%d"}
           {nocache}  {* this part is not cached ----------------> *}
           {if $accessLevel >= $smarty.const._AUTH_ADD}
              <a href="...">Add New</a>
           {/if}
           {/nocache} {* <---------------- this part is not cached *}
         </th>
      </tr>
      <tr>
        <td>
          {assign var="entries" value=$days[j].entries}
          {section loop=$entries name="j"}
             {include assign="title" file="title.inc.tpl" entry=$entries[j]}
             {include assign="popupText" file="popuptext.inc.tpl" entry=$entries[j]}
             {popup ... } {$title} {/popup}
          {/section}
        </td>
      </tr>
    </table>
  </td>
{/section}
</table>

(Above code is not complete nor bug free)

Please do ignore that I am using the {nocache} tag even if I don't like. The template was old and I didn't wan't to rewrite it so {nocache} was the easiest and fastest way Wink

If you want you can send me your sources so I can test it's performance myself too.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Smarty Development All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP