[Seaside] Seaside redirects, really?
kittle31 at gmail.com
Sun Oct 2 07:12:33 UTC 2011
On Sat, Oct 1, 2011 at 10:44 AM, Sebastian Sastre <
sebastian at flowingconcept.com> wrote:
> Hi guys,
> please let me troll about seaside redirects...
> from the docs  one understands the basics of seaside requests
> "...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
> If you really care so much about state you already persisted the model,
> Conclusion: they're evil, they were overrated
> So? come on... I say seaside would be *better without them* (maybe *way*better)
> What you say?
Well ive never run into any problems with the redirects.
But speedups are always good. What would you suggest to fix them?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside