On 4/17/06, Sebastian Riedel <sri@oook.de> wrote:
>
>
> 17.04.2006 15:30 Matt S Trout:
>
> > Sébastien Wagener wrote:
> >> On Wed, 2006-03-01 at 13:27 +0000, Matt S Trout wrote:
> >>> On Wed, Mar 01, 2006 at 06:00:01AM +0100, Sebastian Riedel wrote:
> >>>> 01.03.2006 05:39 Nilson Santos Figueiredo Junior:
> >>>>
> >>>>> On 3/1/06, Sebastian Riedel <sri@oook.de> wrote:
> >>>>>> This is another best practice promoted to be part of core, it
> >>>>>> will
> >>>>>> eliminate namespace collisions like for the famous "login"
> >>>>>> action in
> >>>>>> combination with auth plugins. ;)
> >>>> The application class was from the beginning just meant as a
> >>>> place to
> >>>> interact with Catalyst "internals", load plugins, configure the app
> >>>> and the like.
> >>> And of course, your $c for each request is blessed into that
> >>> class by
> >>> default (unless you set __PACkAGE__->context_class to something
> >>> else).
> >>>
> >> Is it normal that I still have to put the end action into the app
> >> class
> >> (instead of the Root controller) while using DefaultEnd?
> >>
> >> My end action:
> >> sub end : Private {
> >> my ($self, $c) = @_;
> >> $c->log->debug("app end action");
> >> $c->NEXT::end( $c );
> >> }
> >
> > Catalyst::Plugin::DefaultEnd should probably really be
> > Catalyst::Controller::DefaultEnd; I usually have my Controller::Root
> >
> > use base qw/Catalyst::Controller Catalyst::Plugin::DefaultEnd/;
>
> It should be a action class.
>
> sub end : Private : Action('DefaultEnd') {}
Actiually it will be
sub end : Action('RenderView') {}
The module is ready and awaiting the release of Catalyst 5.70. This will
also make overriding functionality a whole lot easier.
Highlight