> I've seen this before ! > > What you have to do is make sure every significant state can somewhat get > back to the server on the next request. > For user-login you have the cookie. > For specific editing context information, you can get some back in having > eo-id encoded within the form. Like having a text field with a name = > 'Book_01_title' that way, you could deduce that you have a text-field on the > title attribute of an eo of entity Book with 1 as the primary key.
They did push the concept further ... they encoded (?bluefish?) those id so that they couldn't be forged. and further still ... but I do not remember it all ! > For persistency and be session independent, you have to make every action a > direct-action and not require a session. You have to see Session as optional > and not rely on it, just consider it as a cache that can boost request > evaluation > > So with a combination of cookies, direct-action and special form encoded name > you could reconstitute most (if not all) of your context. > > In fact I do not remember the implementation, but it must resemble what I > just described. > > It was presented to me in 2000, it was a WO engineer that developed it for a > client, and he showed us his application running, went to a form page, > started to fill it and then stopped the application and restarted it (so > obviously session id was no longer valid), he then submitted the form and the > client did go along as if nothing happened server side. You can now imagine > a farm of wo apps, if one of the instance goes down, no worries, another one > will take the request and respond. > > > Le 2011-12-02 à 08:47, Mahdi Mankai a écrit : > >> Hi, >> >> Thanks for the reply. >> >> I don't really care about the timed out session. I am more looking for >> restoring my whole context even with a new session. >> >> Ajax won't be helpful for me, because I want to plug such a behaviour to an >> existing complex application. It won't be very convenient to review all the >> forms and components. >> >> Mahdi >> >> On 2011-12-02, at 1:54 PM, Jérémy DE ROYER wrote: >> >>> I dont think its possible, timeout is timeout >>> >>> May be you could auto save the form with ajax and restore it in the new >>> session ? >>> >>> Jeremy DE ROYER >>> >>> Le 2 déc. 2011 à 12:11, Mahdi Mankai <[email protected]> a >>> écrit : >>> >>>> Hi, >>>> >>>> I'd like to do something but I am not sure whether it's possible. >>>> >>>> I have a WO application that requires users to login. >>>> >>>> I am storing the user credentials in cookies to avoid having to login each >>>> time. >>>> >>>> I'd like to handle the situation where a user tries to continue working on >>>> the application after his session is timed out. >>>> >>>> Basically, whatever the request is (may be Direct Action or Component >>>> request, with or without form values), I want to get the appropriate >>>> response but with a new session (created using the credentials stored in >>>> cookies). i.e. process the same request but with a different session or (I >>>> don't know if it's possible) restore a timed out session. >>>> >>>> I don't want to extend the session timeout parameter. >>>> >>>> I tried to do something in >>>> handleSessionRestorationErrorInContext(WOContext aContext) in >>>> WOApplication class. But couldn't figure out how to reuse the same context >>>> with a different session. The only thing I was able to do is to redirect >>>> to a specific page. >>>> >>>> For example, I would like users to be able to fill a form, come back >>>> tomorrow, hit save and my application should be able to handle that >>>> smoothly. >>>> >>>> Thanks, >>>> >>>> Mahdi _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
