[Catalyst] [OT] Trouble with Chained Actions and Redirects?

[John Napiorkowski]

--- Wade.Stuart at fallon.com wrote:
> > Wouldn't even need to. It's just an (untested)
> >
> >   sub MyApp::redirect_and_stop {
> >       my $c = shift;
> >       $c->response->redirect(@_);
> >       $c->detach;
> >   }
> >
> > and a call via $c->redirect_and_stop(
> $c->uri_for('/foo', $foo) );
> 
> Or maybe call it redirect_and_detach so other devs
> that may eventually need
> to read/debug the code can guess what it does
> without seeing what your
> definition of "stop" is =)
> 
> always good to use known verbs =)
> 
> -Wade

Yes, but for me it's not about saving the keystrokes,
it's just that it's not intuitive (to me) that
->detach is used to escape processing in Catalyst. 
The word "detach" is a great one for the idea of "It's
like forward but it's not going to return, it's
detached".  I guess I can kind of see it as "It's
permanently detached" but I only think of that now
after all the feedback I've gotten.

I have a lot of programmers with experience writing
mod_perl apps and for them (and me) we are used to the
idea that you can end processing with a location
header and returning the redirect http status code. 
There is no equally obvious method to end processing
in Catalyst, since the detach method is not documented
that way and the word itself does not give me the idea
to use it for that purpose.  Now, in auto methods you
can return 0 to stop processing but that doesn't work
for normal Catalyst actions.  So at first pass I can't
see how to stop processing if I want to.  This is
something I've wondered about for months but until now
it didn't bite me so I was able to ignore it.

Also I think it's intuitive to think that redirect
would function as a end to processing, which is how I
got into this trouble in the first place.  I'm not
saying that Catalyst should do that, because I can see
the very valid reasons why it doesn't, I'm just saying
that in the absence of direction my instincts
developed from writing CGI and mod_perl apps would
lead me to think that a redirect call would function
as a end to the processing.  When it didn't it caused
confusion and misunderstanding.  I am guessing I am
not the only one confused about this.

I'd be happy to offer a small POD patch to the
redirect and detach functions to document that
redirect doesn't actually redirect until you reach the
endpoint in your catalyst chain or sequence of actions
and that this is a good thing because it give you
finer control.  It makes total sense to me now that
you've all spent to time to explain it to me.  Also
that $c->detach is the catalyst way to end processing
a chain right away and fills the role that "return
HTTP_STATUS_CODE" does for mod_perl apps except it's
better because it also you to do some cleanup and
finalization if you need to.

I guess another way to handle this is to write your
own action to handle redirects as I have for handling
not found and other error types.  I have a controller
for this: $c->detach("/errors/not_found", [$errmsg])
which I use for this purpose.  I could create a
$c->detach("/http/redirect", [$url]) to handle this
instead of using the catalyst built in.

Does that all sound correct to you?

--john

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com