[Seaside] Seaside redirects, really?

Sebastian Sastre sebastian at flowingconcept.com
Sat Oct 1 17:44:16 UTC 2011

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

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

Conclusion: they're evil, they were overrated

So? come on... I say seaside would be better without them (maybe way better)

What you say?



[1] http://book.seaside.st/book/in-action/session/life-time

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20111001/60c398e2/attachment.htm

More information about the seaside mailing list