[Seaside] #alwaysRedirect

Avi Bryant avi at beta4.com
Thu Nov 6 07:44:37 CET 2003


One of the design decisions we made very early on when developing 
Seaside was that by default, every request would be split into two 
parts: a request would come in, Seaside would issue a redirect, the 
browser would make a second request, and then Seaside would provide the 
full response.  In very early Seaside, these were known as "action" and 
"view" requests, because all the processing happens in the first 
request, and all the rendering happens in the second one.

I like to re-evaluate design decisions every once in a while, and I'm 
wondering whether to stick with this one.  The advantage is that a 
browser reload is always a completely safe operation - it'll only 
re-issue the "view" request, which means that there can't be any side 
effects.  It also means you're never reloading the result of a POST 
request, so you never get that annoying "do you want to re-submit?" 
dialog from the browser.

The major disadvantage is that on high latency connections, it can slow 
down your application noticeably.  It's especially bad when compounded 
by using HTTP Basic Authentication (which seems to double the number of 
requests in many browsers).  The redirecting (which is optional, 
through the #alwaysRedirect preference) also adds a certain amount of 
complexity to the framework.

What I'm considering is this: by default, links 
(#anchorWithAction:text:) will not perform this redirect.  Forms will 
continue to use POST by default, and so will insert a redirect.  This 
should significantly cut down on the number of roundtrips for an 
average Seaside app.  There will also be variants of the above: 
#anchorWithSafeAction:text:, which will perform the redirect (if the 
action is something that would be bad to repeat on a reload, like 
adding an item to a shopping cart), and some way of designating a form 
to use GET instead of POST, for really simple forms (like forms with 
buttons but no inputs), which will not redirect.

Would this be a change for the better, or for the worse?

Avi



More information about the Seaside mailing list