[Seaside] #alwaysRedirect

[David Farber]

Avi - I'm not really a Seaside user/developer, so I can't really answer your final question as to whether your change would be for the better or for the worse. But I did want to make a few comments.

First, I was intrigued to hear you say that redirecting adds (non-trivial) complexity to the Seaside framework. I built a small framework in Cold Fusion once that also split processing and viewing by issuing a redirect in between. It was really straightforward--which shouldn't be suprising since Cold Fusion doesn't really let you do anything complex.

Second, perhaps it would be useful to move away from talking about POSTs-vs-links and talk about static-vs-dynamic requests. A static request is one that always resolves to a known object/location, like an icon. A dynamic request is one whose ultimate resolution is unknown at the time the request is made. For example, when I hit OK after filling in my username or password, I might wind up back at the form if my username/password is incorrect or I might wind up at "My Yahoo!" if the username and password check out. Yes, dynamic requests are almost always POSTs, but every once in a while you find that you want a link to do POSTy things--just yesterday I had a client ask to be able to login via a GET with query parameters instead of using a POST.

Maybe if the conceptual distinction was emphasized it would be easier to know when you win by paying the price of the redirect.

david

At 10:44 PM 11/5/2003 -0800, you wrote:
>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
>
>_______________________________________________
>Seaside mailing list
>Seaside at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/listinfo/seaside
>
>
--
David Farber
dfarber at numenor.com