Matt S Trout wrote:
> Nate Wiger wrote:
>> If you can send me a pointer to writing a controller base class, I'll
>> certainly check it out. I didn't consider this an option, to be honest.
>> I was trying to model it after XMLRPC, which is nice and easy to load
>> with its :XMLRPC attribute. But I'm open to other possibilities.
>
> "Poke at Catalyst::Base" - each attr causes the _parse_Name_attr method to be
> invoked during which you can do as you will.
>
> Catalyst::Plugin::XMLRPC is a complete disaster of a design cockup and
> considered *strongly* disrecommended. Catalyst::Plugin::Server obsoletes it
> so
> far as I'm concerned.
Actually, I was talking about Server::XMLRPC - great module, again
implemented as a Plugin. It could be argued that it belongs as a
controller base class too, since it does alter the request cycle and add
an $c->xmlrpc (as well as even forward requests to different urls).
Just to throw an idea out, the plugin architecture could be formalized
somewhat. Add a register_plugin() method, for example, that doesn't
allow more than one module to load into $c->{whatever}. A Plugin module
writer would use this to register their plugin.
It could do some simple housekeeping and throw an exception like so:
Attempt to load Cat conflicts with already loaded plugin Dog
Just a thought.
-Nate
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
