I agree that it should be a plugin. This would be very useful for
building dropdown boxes of actions for M:P:Authorization. As long as
we're adding meta-data, what about a method to return the model_class
based on tablename? That would allow use of plural_monikers in the
navbar.
On Thu, 2005-09-29 at 08:15 -0700, David Baird wrote:
> On 9/29/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> > Peter Speltz wrote:
> > > I'd like Dave H s actions sub to be added to core Maypole.pm. One
> of
> > > maypole's strengths I think is that
> > > It returns a list ref of "Exported" actions for a model class.
> Here
> > > it is. I named it
> > > model_actions in my driver :
> > > sub model_actions
> > > {
> > > my ($r, $model_class) = @_;
> > > $model_class ||= $r->model_class;
> > > use Class::Inspector;
> > > my @actions;
> > > for my $method (@{Class::Inspector->methods($model_class)})
> {
> > > push @actions, $method if
> $model_class->is_public($method);
> > > }
> > > return [EMAIL PROTECTED];
> > > }
> > >
> > > Could someone please tell me if this will be put into Maypole and
> > > under what name/synopsis so I can make my code compliant with
> future
> > > release while I'm thinking about it :)
> >
> > I don't think I'm the right person to make a decision, but here are
> the
> > options I see:
> >
> > -1- Add it to Maypole.pm as you suggest. PRO - simple for everybody
> to
> > use. CON - creates another dependency (Class::Inspector) and slows
> down
> > every CGI request.
> >
> > -2- Turn it into a plugin. PRO - you only pay the price if you want
> to
> > use it. CON - slightly more complex to use, one more module to
> maintain.
> >
> > -3- Just document it in the request cookbook. PRO - no module to
> > maintain. CON - harder to discover and use, more likely to get out
> of date.
> >
> > -4- Do nothing. PRO - it's quintessentially lazy and thus Good Perl.
> CON
> > - people won't find it unless they remember it's in these archives.
> >
> > To some extent, what we do depends on how much it is used. How many
> > people are using it? (hmm, that's a question that really belongs on
> the
> > user list)
>
> I think it belongs in a plugin, because there's quite a bit more you
> can do with it, like generating printable reports of the API. I think
> the maintenance thing isn't actually a CON - whoever writes the thing
> is responsible for maintaining it, i.e. not the Maypole core!
>
> d.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Maypole-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maypole-users
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users