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,
>    });
> 
> There would be standard code in the model and view (perhaps inherited
> from Maypole::Config?) that manipulated the symbol tables appropriately.
> 

I recognise the problem, but I don't like this as a solution. You're
spreading code even further into (potentially multiple) unexpected
places. And you need to understand a lot about how Maypole works to
understand how to use this mechanism. And you need to add another
level to the hash, so you can inject code into specific subclasses as
well as the base model.

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.

d.


-------------------------------------------------------
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

Reply via email to