On 11/22/05, Peter Speltz <[EMAIL PROTECTED]> wrote:
> Can anyone think of a cool expample of overriding "adopt" ??    Just
> browsing through SVN and this concept reallly hits me as genius.   Now
> it does someithing really simple, but it is a very powerful hook into
> setting up each model class.
>
> Could this be a  place to implement Model Plugins?
> .
> <bunch of rambling >
>
> No. That should be implementid in a not overridable place.
> However , if Maypole:;Application took the Base Model Class  ,, It
> courld do model plugins easy.  Seems the View and the Model class
> could be passed to maypole application.  I think those are the
> important things to set before calling setup and that would be one
> less thing to worry about.
>
> use Maypole::Application( qw /-Model SuperModel  -View PrettyView
> -Debug 1 Model::CDBIPlus Model::HandyConfig View::Simple
> Authorization/ );
>
> maybe .  Then  M::A just do a push on the ISA of the model and view
> classes  and put
> them in config.   I like it i think.  But I strayed OT. Back to adopt.
>
> Cool uses for adopt.  I cant think of any real cool. I think it should
> get an $r arg for now until config is worked out.  I could have used
> it to set the column_info hashes for my model classes rather than
> overriding setup.
>
> Anyway . . .Maybe I'm onto something with the Model and view plugins?
> Or maybe you already discussed this approach and i missed it?

There was some code to do just this in the experimental Maypole.pm I
posted to the list a while back. It should work fine, but we'd need
some (or at least an) actual model plugin, plus some tests, which is a
more substantial piece of work than actually implementing the thing.
We also need to come to a view as to whether we want to hack @ISA, as
happens with plugins, or do something more subtle involving exporting
symbols. For the model, I'd prefer not to mess with @ISA. I've not got
a lot of experience with exporting symbols in an OO system, I think it
works fine, they're called mixins I think, but again, we'd need a
bunch of tests to keep us straight.

I've flagged this for 2.12 in the wishlist in svn.

We also need to think about the use case. We should be encouraging
people to build their own base model, which inherits from one of the
standard models. And if they have their own base model, they can just
'use' other model 'plugins' directly, rather than via Mp::App. The
cases where it makes sense to plug in model components via Mp::App may
be quite few.

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. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel

Reply via email to