Twisty mazes i do not like in my programming. Definitely something should give here. I can't dive into this muck yet but I can tell you I override setup and use the recommended plugin method.
In my setup the first thing I do is call SUPER::setup. This may be why it works. cheers, 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. > > 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?). 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. > > -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. > > -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? > > Any thoughts? > > 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 > -- pjs ------------------------------------------------------- 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
