[Catalyst-dev] RFC: DWIM redirects

[John Napiorkowski]

--- Ash Berlin <ash_cpan at firemirror.com> wrote:

> Robert 'phaylon' Sedlacek wrote:
> > Jonathan Rockway said:
> >> During a recent IRC conversation, the idea came
> up to implement a
> >> $c->redirect
> >> method that works like $c->forward.  It will
> accept an application path
> >> ('/controller/action', etc.) and will immediately
> halt processing (like
> >> $c->detach('action')) but will issue an HTTP
> redirect to the uri_for the
> >> action.
> > 
> > Sounds great, I'm just worried users will confuse
> $c->req->redirect and
> > $c->redirect. Although, I'm rather worried they'll
> get confused while
> > trying to get help in #catalyst :) How about
> 'redirect_to'?
> > 'external_forward' sounds a bit goofy.
> > 
> 
> $c->redirect is new and more DWIM - most ppl have
> issues with 
> $c->res->redirect not detaching. I'd expect that
> this would help more 
> than cause problems (If you already know about
> $c->res->redirect then 
> there is also no problem).
> 
> -a

I have to agree, I know myself this caused a lot of
trouble and confusion.  I thinks this confusion
happens because a lot of the time
$c->request->redirect sort of does what you want,
particularly if you are using any of the suggested
default end actions, since those automatically do the
right thing with redirect statuses.  It's only when
you  'go off the reservation' and start creating stuff
that doesn't use the renderview action class or need
to perform redirects that are not the very last
statement in an action that cause you a lot of
trouble.  I mean this drove me crazy:

sub this_action :Path
{
   my ($self, $c) = @_;

   ## Some code...

  if( $ERROR )
  {
     $c->request->redirect($ERROR_URL);
  }

  ## More Stuff that you don't want to happen if
  ## there is an error but will happen with the
  ## way things currently work.
}

So in general I think it's more DWIM for most of what
I need and for the rest you can use the old syntax for
greater flexibility or even create a plugin to
override or extend the $c->redirect behavior.  I can
see making a plugin that would automatically Flash the
current Stash before redirecting.

Some concerns I have (which have probably already been
raised but anyway)

1)  I am also concerned (as was mentioned) that maybe
we should used a different method name, although I am
not so concerned as to want to argue for it
forcefully.  If the consensus is this won't be trouble
that I can go along with that.  To bad changing
$c->req->redirect to something more clear isn't like
to be possible at this point, although maybe we could
create a different method name and alias this to it
and make the current method as depreciated to be
removed at some point in the future?  

2)  I can't read the proposed source for some reason,
I assume that $c->redirect would accept some
parameters for setting the HTTP Status code?  I tend
to be a stickler for distinguishing between 302 Found
and 303 See Other redirect types.  What are we
proposing to be the default?

3)  Since it's come up a few times maybe we should
make an easy way to have post parameters preserved?  I
know this is sort of a misuse of HTTP but people have
asked for an easy way to do this from time to time.

--john


> 
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev at lists.rawmode.org
>
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
> 


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