On 10/21/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-10-20 at 21:54 +0100, David Baird wrote:
> > On 10/20/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> > > The plugin needs to initialize, and since there's no standard mechanism
> > > it uses the technique Dave suggested in Maypole::Manual::Plugins -
> > > override Maypole::setup.
> >
> > I think this method *is* standard - for Maypole. I simply documented
> > what was already present in a number of plugins.
>
> I think it's common practice but that doesn't make it a standard. (I
> like your documentation though! It's good to have it out in the open and
> it discourages people from implementing yet more ways :)
>
> How setup works in its interactions with the model and loader is
> complicated enough without overloading it with yet more semantics to do
> with plugins, IMHO.
Very good point.
[snip]
> >
> > I think this is a reasonable solution. It's just
> >
> > {
> > no warnings 'redefine';
> > sub Maypole::setup {}
> > }
> >
> > Um, not sure if 'no' is a compile time thang, probably is.
>
> That's pretty much the code I have at the moment (I actually redefine
> Maypole::setup rather than delete Maypole::setup and create a local sub
> in my driver, but that's neither here nor there).
>
> But to me it still looks very much like the kind of code we were busy
> trying to remove a while ago.
You're right.
>
> > > -2- Now the 'naughty' code has been removed, setup looks to me very much
> > > like something that should be in Maypole::Model::Base rather than
> > > Maypole.
> >
> > I don't think so. Then you'd have a base class doing all kinds of
> > stuff with its derived classes, but base classes are not supposed to
> > know anything about that.
>
> So it's better to have the code in a completely unrelated class???? I'll
> come clean: IMHO, it's scary the way the whole setup, setup_database,
> loader, loader-generic, loader-mysql, inheritance, adopt,
> $config->classes etc etc THANG is put together. But I expect a redesign
> would break backwards compatibility somewhere.
>
> > > -3- We could do with a better way to initialize plugins. Yes, it's me
> > > asking for a hook :) But I seem to remember Perl has a standard one -
> > > import - perhaps we could use that?
> >
> > The problem with import is that it's called at compile time, which is
> > way too early for Maypole, because the model hierarchy is set up at
> > runtime.
>
> Well, it's called whenever the framework wants to call it :) But, OK,
> let's use a different name so as not to confuse people.
Ah, I see, you're meaning load plugins via require (just as they are
now), then call import() manually. I'd class that in the 'tricky stuff
we'd like to remove' category as well. Better with a different name as
you say.
> My point is that
> I think there should be a separate mechanism that plugin writers can
> rely on to initialize their plugins. It shouldn't be bodged in as a
> side-effect of the model initialization (setup) or the view
> initialization (init). That complicates life for plugin developers and
> framework developers alike.
>
Yes. This is looking like a consequence of not cleanly separating the
controller from the model. Also a consequence of having methods that
do more than one thing.
How about renaming setup() as setup_model(). The new setup() would
then just call setup_model(). So setup() becomes the official hook for
plugin initialisation, and setup_model() for model initialisation.
Then you can override setup_model() to do things your way.
> > > Any thoughts?
> >
> > I don't see any downsides to using init().
>
> I'll give it a go.
>
> > I don't have the Path::URI code handy, but I seem to remember the
> > setup code is used to build a URI object representing the uri_base?
> > This seems unnecessary, I'm sure it's not expensive to create URI
> > objects from scratch in each call.
>
> I was concerned that the POD for the URI module explains how to
> circumvent it with REs in case of performance trouble :) I guess it
> could potentially be called quite a lot.
We're hitting the database many times per page load, I doubt if URI
will ever be a bottleneck.
d.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
