[Seaside] Seaside redirects, really?

[Philippe Marschall]

2011/10/1 Sebastian Sastre <sebastian at flowingconcept.com>:
> Hi guys,
> please let me troll about seaside redirects...
> from the docs [1] one understands the basics of seaside requests processing:
> "...All subsequent requests are processed the same way. First, Seaside gives
> the components the ability to process the callbacks that have been defined
> during the last rendering pass.

Uh oh, that's no longer true.

> These callbacks are usually triggered by
> clicking a link or submitting a form. Then Seaside calls
> WAComponent>>updateUrl: of all visible components. This gives the developer
> the ability to modify the default URL automatically generated by Seaside.
> Then Seaside redirects the user to the new URL. This redirect is important,
> because it avoids processing the callbacks unnecessarily when the user hits
> the Back button. Finally Seaside renders the component tree..."
> so, here is what we know about seaside redirects
> 1. they add latency (UX on mobile seaside apps, hello?)
> 2. they complicate httpd configurations (and man! they don't need help to be
> a pain)

How so?

> 3. actually, seaside redirects complicate everything at a questionable price
> for a questionable gain (that's why I'm kicking the table about this)

What gets more complicated?

> If you really care so much about state you already persisted the model,
> right?

You persist UI state (like which column is stored which way)?

> Conclusion: they're evil, they were overrated
> So? come on... I say seaside would be better without them (maybe way better)

Nope, but if you feel that way you can disable them and live with the
consequences (like that nice POST resubmission warning).

> What you say?

Cheers
Philippe