On 10/24/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-10-22 at 13:39 +0100, David Baird wrote:
> >
> > We could maybe break setup_model() into a couple of sub-hooks, but I
> > think anyone who needs to override setup_model() should understand the
> > framework well enough to know what bits to replicate and what bits to
> > modify in their own setup_model().
>
> OK. I tried this and it does mean that I can just override setup_model
> in my driver. That's good! But doesn't it leave a couple of issues
> unresolved?:
>
> -1- plugin writers define their own version of setup, but within it they
> still have to call NEXT::DISTINCT::setup. I'd prefer to see a solution
> where they just define a naive setup method that does their own
> initialization and then have the framework (specifically, the plugin
> loading code) worry about making sure those methods get called. If we
> give the new method a new name (setup_plugin?) it should be backwards
> compatible.
I see pros and cons, and I'm not sure where the balance is. The
advantage of the current arrangement is that the code in Maypole is
simple, therefore bug-free. The con is that it complicates the code
that plugin authors must produce.
But building an alternative is not straightforward. We'd need to
register plugins as they are loaded, then call their setup_plugin()
methods *after* the main setup() has been called, because some plugins
rely on the model being available when their setup() runs. Unless you
can see a simple alternative, I think adding setup_plugin() should
wait until 2.12.
Maybe we could just munge the symbol table for Maypole::Plugin::* entries.
And another thing. The current setup allows a plugin author to control
whether the plugin's setup() code is run before or after the main
setup() has completed. This allows things like
Mp::Plugin::Config::YAML and M::P::C::Apache to run first, then allow
the rest of setup() to proceed after having populated the config
object. Maybe we need setup_plugin_before() and setup_plugin_after()
and the API is growing and I suspect the benefits are disappearing.
Better docs for Maypole::setup() may be all we need?
>
> -2- I still think the code in Maypole::model_setup is really model code,
> not controller code. I agree that moving it all to Maypole::Model::Base
> is wrong; I suggest Maypole::Model::CDBI or Maypole::Model::MyModel as
> well. Something like (untested!):
>
> In Maypole::setup:
>
> Maypole::Model::Base->setup_model(@_);
>
> In Maypole:Model::Base:
>
> sub setup_model {
> my $class = shift;
> my $calling_class = shift;
>
> $calling_class = ref $calling_class if ref $calling_class;
>
> my $config = $calling_class->config;
> my $model = $config->model ||
> $config->model("Maypole::Model::CDBI");
> $model->require;
> die "Couldn't load the model class $model: $@" if $@;
> $model->setup_model($calling_class, @_);
> }
>
> In Maypole::Model::CDBI:
>
> sub setup_model {
> my $class = shift;
> my $calling_class = shift;
>
> my $config = $calling_class->config;
>
> ... the rest of the existing Maypole::setup code goes here
> }
>
> ... and in Maypole::Model::MyModel, I just need to define setup_model
> differently.
>
> Or am I missing something here?
>
I have a problem with hard-coding the class name, but it took a while
to figure it out. What we have here is a factory pattern - we want to
call a method on a class, but first we need to identify and load the
appropriate class. We could imagine a Maypole::Model::Factory class,
with a setup_model() method. Or we could just put the setup_model()
code somewhere convenient - it's still a factory pattern, just without
a dedicated class. In this case, the primary determinant should be
convenience and low coupling, which I would argue means placing the
code in Maypole::setup_model(). That is, what you have in
Mp::Model::Base::setup_model(), I'd put in Maypole::setup_model(),
close to the only code that calls it. I'd agree with your
Maypole::Model::CDBI::setup_model().
At least, that's what I think today.
d.
-------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
