Nah this is fine with me. I always wanted to be able to do that anyway. However, we _should_ maybe also implement the possibility to pass stuff to __construct... dunno... something like
Controller::getModel(string moduleName, string modelName, array initializeParams, array constructParams, bool extractConstructParams) With extractConstructParams set to true, we'd pass the values of the array to the constructor instead of the entire array. That way, we could access virtually any class through getModel. Also, I have some working and well-tested code that supports the use of Singletons with get(Global)Model I could contribute... while we're at it, we definitely should implement this, too. I needed singleton support in models from like the second day after starting to work with Mojavi. - David > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bob Zoller > Sent: Monday, June 20, 2005 4:45 AM > To: Agavi Development > Subject: Re: [agavi-dev] initialize() vs. __construct() > > Ok.. I see the reasons for keeping initialize(). Mike seems ok with > providing the ability to pass params to certain (all?) calls to > initialize() methods.. anyone disagree with that piece? > --Bob > > On 6/19/05, David Zülke <[EMAIL PROTECTED]> wrote: > > > So this message has two purposes: > > > > > > 1. to discuss initialize() vs. __construct(), at least as it relates > > > to Models.. possibly other places. > > > > > > Currently, Agavi uses the initialize() method (basically) instead of > > > relying on the __construct() method. Is this necessary, or might we > > > simplify things a bit by using the builtin __construct method? I > > > realize this would be our first major BREAK in compatibility with > > > Mojavi. > > > > I don't really see a reason why we should do that. One reason why > > initialize() is uses might be that you can "drop in" a class without > > modifications and use them as a model. There certainly is some > redundancy > > there, but you know it - never change a running system ;) > > > > - David > > > > > > _______________________________________________ > > agavi-dev mailing list > > [email protected] > > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev > > > _______________________________________________ > agavi-dev mailing list > [email protected] > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
