On 10/20/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> I've just stumbled back into a twisty maze of passages. There are
> markings on the wall: setup, setup_database, loader->new and more ...
>
> I just tried to add my Path::URI plugin to my main app but it didn't
> work. It turns out this is because of a mismatch between how the plugin
> initializes and my customized database setup mechanism.
>
> 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.
>
> 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.
>
> -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.
>
> -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.
>
> Any thoughts?
I don't see any downsides to using init().
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.
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.
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
