[Catalyst] error handling (Chain where ajax and non-ajax actions chain off)

[Eden Cardim]

>>>>> "David" == David Schmidt <davewood at gmx.at> writes:

David> I tend to put related actions into a controller. E.g.: all actions
David> dealing with artists into the Artists.pm controller and so on.
David> You advise (as I understood) means having an additional controller for
David> every controller where I want to support XHR requests.

David> Is there a flaw in how I lay out my controllers?

Personally, I tend to treat controllers just like any other class, I factor them
out when the implementation asks for it. For this case, I think breaking down
into separate classes makes sense so you can leverage the catalyst action flow
to model your application into layers that get more specific as you drill down
the url hierarchy:

/artist   => calls MyApp::Controller::Root::end()
/artist/1 => calls MyApp::Controller::Root::end()
/artist/1/xhr => calls MyApp::Controller::Artist::XHR::end()

also, since $c->controller (without any arguments) returns the controller of the
current dispatched action, you can rely on it to determine the context of the
generic actions, for instance, your error handling:

$c->detach($c->controller->action_for('error_404'));

in Controller::Artist:

sub error_404 :Action {
  my($self, $c) = @_:
  $c->stash->{template} = 'error_404.tt'
}

in Controller::Artist::XHR:

sub error_404 :Action {
  my($self, $c) = @_;
  $self->status_not_found($c,
    message => 'Cannot find what you were looking for!'
  );
}

-- 
     Eden Cardim            Need help with your perl Catalyst or DBIx::Class project?
   Software Engineer                   http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.        Want a managed development or deployment platform?
http://blog.edencardim.com             http://www.shadowcat.co.uk/servers/