> >  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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to