[pLog-svn] Smarty caching problem

[Jon Daley]

 	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