On 9/16/05, David Baird <[EMAIL PROTECTED]> wrote:
> On 9/16/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> > I wrote:
> > > I'd like to see Maypole->config->model_options, just like
> > > Maypole->config->view_options.
> >
> > One reason that I'd like to see this is because we can use it as a way
> > to extend standard interfaces. For example, there are lots of places in
> > lots of code in plugins and individual applications where authors inject
> > new methods into the model. And as many different methods of doing it
> > are used as people can dream up. So I'd propose that both view_options
> > and model_options support a standard key, say 'inject' that adds or
> > overrides methods in the model or view. You would write something like this:
> >
> > BeerDB->config->model_options({
> > inject => { do_pager => sub {
> > # override pager to extend function
> > },
> > drink => sub : Exported {
> > # add a new action!
> > },
> > },
> > other_options => as_required,
> > });
This looks a little like a catalsyst app , Dave. What have you been
doing ? : ) I think writing your own model and view class is the
way to go. I think a tip that could go in Kieren's beginner's
guide is:
When you start developing, immediately subclass the Model and View of
your choice and configure your app to use your subclasses. Even if
they do not change any thing you will be ready to override, add
features, and patch without being tempted to hack up a CPAN module or
put code in a place it does not belong.
> The problem we need to solve is how to deliver little packages of code
> that people can incorporate into existing models. I think it's fair
> enough to expect them to write a custom model/view, which inherits
> from one of the standard ones:
>
> package MyModel;
> use base 'Maypole::Model::Foo; # eg CDBI - something that inherits
> from Mp::M::Base
>
> __PACKAGE__->model_plugins( qw/ FunkyEdit BetterSearch BeerMakerTools / );
> 1;
>
>
> model_plugins() is defined in Mp::M::Base. It require()s
> Maypole::ModelPlugin::FunkyEdit etc., and calls their import() methods
> from within the MyModel namespace. ModelPlugins use standard Exporter
> techniques to export code to us.
>
> Not confident this would work for methods with attributes though, but
> I'm sure we could figure that out.
>
This is good Dave. Is it written? Model plugins will allow a lot more
sharing of good model code as there is currently know way to do that.
I think the small package philosophy is right on. I can envision
plugging in actions for all sorts of tasks like SendEmail which would
come with a create_email action and a do_email action to process it.
Then all i have to do is write the template.
cheers
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
