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

Reply via email to