[pLog-svn] r1720 - in plog/branches/plog-1.1-ben/class: action action/admin cache

Oscar Renalias phunkphorce at gmail.com
Tue Apr 5 09:58:34 GMT 2005


it does have a constructor :-) If no constructor is specified, PHP
will call the constructor of the parent class or otherwise we couldn't
use Model::_db . So in other words, the connection to the db is still
established via the Model constructor.

Another alternative would be to move all db connection stuff to
Model::Execute(). If Model::Execute() is used, then check if $_db has
been initialized and if not so, then proceed with the initialization.
This would allow us to implement the caching at the Model level while
still using your performance gains (lazy load of the big db classes
and a deferred connection to the db) It would also help to make the
caching somehow more generic so that caching features are easier to
implement in all the classes that extend Model.

I think it could work... 

About the $extendedInfo parameter, it was used to load more stuff from
the blog but that was removed shortly before 1.0 so it's not needed
anymore and I think it can be safely removed.

Oscar

On Apr 5, 2005 12:44 PM, Benjamin Krause <ork at orkland.de> wrote:
> Benjamin Krause wrote:
> 
> > the problem with blogs() is, that it extends Model, and calls model().
> > this starts a hugh include process and connects to the db. i want to
> > avoid the includes and the connection to the db.. now with the extra
> > BlogInfoManager we do not have a connection to the db.
> 
> okay.. correction to my post.. blogs doesn't have a constructor.. maybe
> we can work the cache into Blogs()..
> 
> what's that about the extended info?
> 
> function getBlogInfo( $blogId, $extendedInfo = false )
> 
> Ben
> 
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.plogworld.net
> http://devel.plogworld.net/mailman/listinfo/plog-svn
>



More information about the pLog-svn mailing list