perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ihnen <dav...@norchemlab.com>
Subject Re: a2c controller method names
Date Fri, 02 Jan 2009 16:59:43 GMT
Mark Hedges wrote:
> I wonder how easy it would be to add controller subroutine
> attributes for which ones are allowed or not, ala Catalyst,
> instead of the controller having to provide an
> 'allowed_methods' method.
>   
Sounds like something JSON::RPC::Server::CGI does with :private and 
:public modifiers on the subroutine definitions, I think they're called 
'fields', might be worth a look to see how they did that.

A thought on this matter particularly.

Though JSON::RPC::Server::CGI was just fine about calling my methods 
with its dispatch, it could not find the ability to instantiate my 
object first.  In fact, it always called them in static context with 
itself as the first parameter, which I found quite limiting.

This simply didn't work for my object structure and way I wanted to OOP 
the program.  (I got around it by making a static class that implimented 
an allowed_subroutines function that instantiated and effectively 
manually delegated calls to the appropriate subroutines, blowing the 
nice :public list right into irrelevancy)

It would have been nicer as a dispatching framework if it either A. 
would instantiate my object (through a defined interface like 
->new($server)) first THEN call the method or B. defined a 
hook-handle/decline interface not that different from apache so that I 
can custom define how you check for availability (rather than the 
:public list or ->can), instantiate if relevant, and call subroutines in 
my particular object.

I guess I'm saying consider the interface flexibility as you design the 
framework - there may be interest in doing something in the realm of 
setup before calling the method.

David


Mime
View raw message