[Catalyst] Re: Redispatching actions

A. Pagaltzis pagaltzis at gmx.de
Tue May 22 04:00:14 GMT 2007


* Bernhard Graf <catalyst2 at augensalat.de> [2007-05-21 23:40]:
> Roland Lammel wrote:
> > I find it far more easy to actually perform a redirect at the
> > end of an action, that is intentional for the user and the
> > developer. I havn't come across any problems using redirects
> > (not even on mobile devices), so what kind of problems are
> > you referring too?
> 
> - Loosing state within one http request or maintaining
>   additional overhead to keep it beyond the redirect

Where’s the fundamental difference in effort between maintaining
a request token and maintaing explicitly addressable state?

> - imposing additional load to the server

Premature optimisation. If you use redirects wisely and expose
state in URIs, you can make many more things usefully cachable.
The best optimisation is not to run any code in the first place,
and if more things are cachable, more requests will be served
from caches.

> - trouble GET after POST under mod_perl as described in
>   http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests
>   Well, actually I suspect Catalyst already does the right
>   thing, but I was bitten by this issue long ago in the
>   pre-Google era when you could hardly find anything about this
>   on the WWW.

Right. “This is how it has always been done around here, and
we’re not going to change that now.”

> Whenever I have to fix somebody else's web application (usually
> PHP), the number of HTTP redirects is inversely proportional to
> the quality of the code. So probably that is the main reason
> why I try to avoid them personally.

Yes, redirects can be used as crutches to paper over a bad
design. Then again, request tokens can be used as crutches to
paper over a bad design.


* Bernhard Graf <catalyst2 at augensalat.de> [2007-05-22 00:00]:
> A. Pagaltzis wrote:
> > Not only that, but your choice causes the following sequence
> > of events:
> >
> >     User: *hits Back button*
> >     Computer: This page has POSTDATA. Resubmit it?
> >     User: (thinks) What the?! Hmm… err…
> >     User: *hits OK*
> >     Computer: Ack! You tried to resubmit a form! No cookie!
> >     User: @#$&!!
> >
> > Compare to the alternative, where successful submit produces
> > a redirect:
> >
> >     User: *hits Back button*
> >     Computer: *goes back a page*
> >
> > Guess which one will annoy users less.
> 
> Written very nicely. Actually both variants are designed to
> keep posting data twice, right?

Sure. And one of them requires extra code complexity and
significantly degrades usability, the other works smoothly
with no extra server-side logic.

> > You said absolutely nothing to address the “wrong URL”
> > problem Matt mentioned, btw.
> 
> What wrong URL? My example showed that
> http://example.com/data/update is virtually equal to
> http://example.com/data/view if not posted from a form.

Of course they are virtually equal – after all they are equally
terrible. If you lay out your URI space in that manner, it’s no
wonder that you can’t understand why redirects are good.

> > Of course, you can spend your days writing code to fight the
> > way HTTP works. It’s up to you to judge whether that is a
> > worthwhile use of your time. But I do think you’d be happier
> > and your code simpler and more robust if it didn’t try to cut
> > against the web’s grain.
> 
> I don't fight HTTP. A link is one thing, an action is a
> different one. While the first always is a static route to some
> other place, the latter *acts* upon (input) data and the
> resulting output depends on this input data and potentially
> other data as well (like this RequestToken status, that tells
> that the transaction has already been processed when trying to
> redo the action, or the request method not being POST). 

Right. First you say you don’t fight HTTP, then you immediately
launch into an explanation of how you put verbs in your URIs.
Something is wrong with this picture.

> > Redirects are one of the greatest features of HTTP, actually.
> 
> As GOTO is one of the greatest features of Basic - and of
> course Perl.

… come again? What do GOTOs have to do with anything?


Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>



More information about the Catalyst mailing list