On 10/25/05, David Baird <[EMAIL PROTECTED]> wrote:
> > Are there any disadvantages of calling setup in a BEGIN {} block?
> > (thinking documentation).
>
> If you are using your own custom model, then calling setup() inside
> BEGIN will set up the model on top of Maypole::Model::CDBI, instead of
> using the custom model, because setup() is being run at compile time,
> whereas you specify a custom model at run time.
>
> Same goes for custom view classes.I think we need to document using customised vs standard classes, a lot of Maypole stuff JustWorks(TM) with the standard classes, and this technique builds on this without much mucking about. As it's clear kieren is using vanilla, out of the box, bog standard, recycled classes rather than nifty spiffy super ajax web2.0 classes, we don't need to worry about that ;) > I always set up all the config, then call setup() at the very end of > the driver, just in case there are any config settings used in the > setup() of any plugins I'm loading. The opposite of calling it inside > BEGIN. Currently I use 0 plugins. Probably this is bad, but it means I have little idea on this kind of thing and could do with somebody writing a quick guide to using plugins and mixing them with your own custom code nicely. > What Simon is advocating is a way to put model methods into your > driver class. In my opinion, Just Say No. If you must put model > methods from multiple packages in a single file, at least put them in > your custom model, rather than in the driver. Remember, model classes > inherit from Maypole::Model::Base, whereas the driver and plugins > inherit from Maypole.pm. Putting model methods in the driver is > confusing and error prone. This is kind of true, but the Driver could be seen as the controllor, and if you are retro-fitting Maypole ontop of, for example, an existing CDBI model/schema then simon's suggestion works quite nicely and seems a quick and easy step in adding a maypole frontend to a cdbi db. I suppose it would be best to lay out the alternatives based on your needs, the tutorial pdf simon wrote covers the intro stuff very well but we need to flesh out using your own models, common plugins, etc. > > Presumably writing "use Maypole::Application qw(-Setup);" (given the > > caveats in the Maypole::Application pod )is equivalent? > > Almost, but note that you can only do this if you set up all the > config data first. That means using Maypole::Plugin::Config::YAML or > Maypole::Plugin::Config::Apache [0]. You get the equivalent of what I > was advocating - all the config is set up before setup() is called. > [...] > [0] Or you could specify the config settings inside a BEGIN block, > placed before the use Maypole::Application statement. But don't do > that ;-) Seems ok to me, so long as any caveats in doing so are documented. Speaking of documentation - who fancies doing a talk on Maypole for the LPW on 25th November (City University, TBC by wednesday night) A. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Maypole-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-users
