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
