[pLog-svn] Smarty caching problem

Mark Wu markplace at gmail.com
Mon Jan 30 13:40:16 GMT 2006


Christoph:

mmmm .... 

1. Did you already solve the {dynamic} block problem ?? This problem is not
easy to solve, you have to write a "smarty plugin" to pass the dynamic
value, take a look at:
http://www.phpinsider.com/smarty-forum/viewtopic.php?t=5095
2. I don't think use the isDynamic() solve this problem, it just let the
user know the plugin is dynamic, but .... It still not solve the real
problem. The plugin can not used insdie {dynamic} block

That's why I said forgot {dynamic} block. 

We have to implement the "dynamic" inside our plugin, not let user use the
{dynamic} block to make the plugin dynamic ...

There are two ways to solve this problem if we don't want the plugin
developers to develop "smarty plugin":
1. User javascriipt to pass the dynamic value to page (no matter use ajax,
or from sessions/cookies). 
=> User use {$pluginxxx->showStats()} in templates. It will render as
<script type="text/javascript" src="plugins/pluginxxx/stats.js">, and loads
the statistics data to the front page.
2. Fetch the plugin template in non-cache parameter ( Kindly take a look at
secret plugin).  

Mark

> -----Original Message-----
> From: plog-svn-bounces at devel.lifetype.net 
> [mailto:plog-svn-bounces at devel.lifetype.net] On Behalf Of Jon Daley
> Sent: Monday, January 30, 2006 9:09 PM
> To: plog-svn at devel.lifetype.net
> Subject: Re: [pLog-svn] Smarty caching problem
> 
>  	Ah, very good work.  Yes, I agree with your statement 
> that only the plugin author knows.  I suppose it is possible 
> that a user doesn't use the dynamic tag, even if the plugin 
> author thinks you should, but perhaps we can ignore that?
>  	So, we would add a new function to plugins (should be 
> able to default to returning false in the parent class, 
> right, so current plugins don't have to be modified)  
> isDynamic() or something like that.
>  	Then when deciding whether to load the objects, we call 
> that and then load them if necessary?  That sounds good to 
> me.  And I think Oscar will be happy with that too, because 
> the plugins that aren't dynamic will still follow the "old" 
> path, and run as quick as they did before, etc.
>  	When going down the dynamic path, is the template 
> effectively never cached, or will smarty do the right thing 
> and cache the parts that can be cached, and only not cache 
> the dynamic portion?  I suppose this means the HTTP cache 
> won't ever be used?
> 
>   On Mon, 30 Jan 2006, Christoph Feddersen wrote:
> 
> > Ok, I did some some research on this using the 
> authentication plugin.
> >
> > The error "Call to a member function on a non-object in ...
> > ^post.template.inc" is not a smarty or {dynamic} block issue.
> >
> > Lifetype behaves like this:
> >
> > Check if template caching is enabled
> >
> > if enabled, see if we have a cached template and if it's still valid
> >
> > If that's true, it doesn't load the plugins and most of the 
> objects at all.
> >
> > When rendering the cached template, smarty looks for the objects in 
> > it's context, but they aren't there -> error
> >
> > I identified two spots where this handled:
> > class/action/defaultaction.class.php line 71-74
> >
> > class/view/blogview.class.php render()
> >
> > The posts are set at the very end of the function, which is never 
> > called when using a cached template.
> >
> > So how to get around this?
> > Both, the defaultaction and blogview objects cannot decide if
> > a) a template contains a {dynamic} block or not
> > b) a plugins needs standard lifetype objects (posts, articles, 
> > comments,
> > user) to work with or not
> >
> > The only one who knows is the plugin author. So this 
> information may 
> > be stored in the plugin.
> > 1) a flag to set if this plugin is dynamic or not
> > 2.a) an array to define the needed objects
> >
> > This properties could be changed in the above mentioned 
> functions to 
> > load only these objects. What do you think of it?
> >
> >
> > Jon Daley wrote:
> >>     Yes, that is what I was talking about.  The problem 
> occurs with 
> >> using any lifetype class inside the dynamic block, which 
> is what you 
> >> have to do in order to get a lifetpe plugin.  The plugins I have 
> >> looked at porting, are the authentication and google plugins, both 
> >> currently sitting in the unported folder in subversion.
> > _______________________________________________
> > pLog-svn mailing list
> > pLog-svn at devel.lifetype.net
> > http://devel.lifetype.net/mailman/listinfo/plog-svn
> >
> 
> **************************************
> Jon Daley
> http://jon.limedaley.com/
> 
> Truth is beautiful, without doubt; but so are lies.
> -- Ralph Waldo Emerson
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://devel.lifetype.net/mailman/listinfo/plog-svn



More information about the pLog-svn mailing list