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.
> > That worked fine with BeerDB but fails with my app. That's because my
> > app is seriously strange :) My driver/controller/application code is
> > produced automatically from the database schema via a code generator.
> > The skeleton code initializes the database connection and model
> > subclasses itself in the way that I want - it doesn't call
> > Maypole->setup or $model->setup_database.
> >
> > So to fix the problem, I could modify Path::URI to use some other
> > initialization hook (Maypole::init, maybe?).
>
> Quite possibly.
>
> > But I thought a better
> > solution might be to wrap my custom database initialization code into
> > methods called 'setup' and 'setup_database' that override those methods
> > in Maypole. That way would bring my application a little closer to the
> > mainstream.
> >
> > So I started reading the Maypole docs to remind myself what the
> > interfaces to those methods are, so I can override them. And got lost in
> > a twisty maze :(
> >
> > It seems to me:
> > -1- it's hard to override Maypole::setup because the recommended
> > technique for plugin initialization doesn't work when you do. AFAIK, I
> > would have to directly modify Maypole's symbol table (to delete its
> > setup method or inject my own) to make it work again.
>
> 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.
> > -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. 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.
> > 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.
> BTW, I stole your code and put it in Maypole::make_uri in svn (but I
> paid my dues by writing a bunch of tests. I know, goes against the
> grain). I took make_path from LinkTools and put it in as well,
> re-written to use make_uri(). Have a look, let me know what you think.
Thanks for the tests! I'll see if I can use them for Path::URI.
I already gave my views on the idea of make_uri and make_path
(http://sourceforge.net/mailarchive/forum.php?thread_id=8417945&forum_id=44077)
but basically I think it's better to use make_uri in templates and I think it
would be better to replace parse_path with parse_uri rather than add extra
hooks to it. We should manipulate objects not strings.
Cheers, Dave
-------------------------------------------------------
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
