I think that the two of you are using "break" in different ways. Alex, you mean it doesn't do what the user expects it to do. Marius, I think, means that the application crashes.
I agree that this is a nasty behavior. One could say that it's the user's responsibility to keep track of their session time, but I don't subscribe to that. I try to make my sites as user friendly as possible. Another scenario is that the session doesn't expire, and the user walks away from the terminal without closing the browser. Then I sit down, find his half finished form and finish it for him. Isn't that equally broken? Maybe more so? The issue here, as I see it, has little to do with continuations per se, and much to do with application design. On my sites, for example, when a user requests a page, the uri of the page is stored. If the user is not authenticated -- possibly because the session timed out -- then she is redirected to the login page. But after login, the site redirects to the original page that she requested. There is no reason you can't temporarily store form data -- if I can store a GET, you can store a POST -- and then if the user chooses to log back in, redirect and repopulate the form, or even provide a confirmation dialog asking if he/she wants to go ahead and post the form data. Why more sites don't do this is beyond me. It's not a difficult programming task. I'd love to see something like that built in to Lift (or at least made very easy). Another option is to store form data as it's entered. I have a survey site that does this right now (albeit with some bugginess). Put it in a temporary table. Then when the user logs back in, give him the option to return to the form and complete it, or delete the partial form data, or leave it for later. There are lots of ways to make sites better without giving up the power of continuations. Chas. Alex wrote: >>> There is no reason for instance >>> when someone is submitting a news group posting to bind an empty >>> posting in a closure and store it on the server, thereby breaking the >>> application in any number of cases: >>> 1) The session times out because the user got distracted or lost their >>> connection temporarily >>> 2) The user abuses the back button >>> 3) The server fails over (assuming there is no memory replication) >>> 4) There is a temporary connection failure and the user reloads >>> 5) The server is restarted >> I don't see how that would break the application. The function mapping >> is cleared is the session times out or it is terminated. Furthermore >> Lift has a garbage collection mechanism that removes the functions >> that are not utilized. >> None of the above cases breaks a Lift application ... if the >> application itself is correctly designed and implemented. > > How does this NOT break an application? If the session is expired and > the function mapping is cleared, what happens when the form is > submitted? Breakage.... If someone is in the middle of writing a > long essay, or building a travel reservation (this happens to me all > the f'in time on most travel sites) then it's gonzo. "Sorry we lost > all your work. Please start over." The alternative is to persist in > the database which is worse than on the client. > > If you can tell me how an application can be "correctly designed and > implemented" to avoid this I'd be very interested. I am not > diametrically opposed to this, but I don't see how it's avoidable in > any reasonable way. > > >>> All of the above cases are recoverable with what, IMO, are properly >>> designed frameworks that minimize server-side state. Those are the >>> things that taught us state should be stored in the client whenever >>> possible. >> Yes and no. I agree with state minimization but adding burden to >> client side doesn't solve much in many cases. > > Yes, it does. > > With 'stateless' frameworks: > > 1) Form submits: post = "Long agonizing post" > 2) Session is expired so user is redirected to login page. Post is > stored temporarily. > 3) User logs in and is redirected to posting page filled out with > their post. > 4) User resubmits > > With Lift > > 1) Form submits: B2345235DSFGA = "Long agonizing post" > 2) Function mapping has been cleared. Application panics and has no > idea what that junk was. > >> With a bit of care for design this can be taken care. For instance if >> you have an Ajax form and the request fails, > > And if the session is expired, the entire client page is invalid and > the page has to be reloaded... > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
