Re: Restoring session after timeout.
Re: Restoring session after timeout.
- Subject: Re: Restoring session after timeout.
- From: Pascal Robert <email@hidden>
- Date: Fri, 02 Dec 2011 12:39:02 -0500
REST/DirectActions is not perfect, personally I use them for "public" stuff, where we only need basic state and we can assume most people will use the back button and that they might fill a form in four hours. I wouldn't use any D2W or "regular stateful" for a public app that is mostly read-only.
As for Dojo/Gianduia/whatever, I see them as Git for Web apps, in the sense that you make changes locally and after that you can send them back to a central source. This is what node.js like: most work done on the client, and the server part is mostly a broker to manage conflicts and act as a datastore and offer "sync services" between apps.
> I can see how this could work for simple CRUD stuff. It seems this would break down when it comes to complex backtracking/flow though.
>
> Let's say I query -> list -> edit list object -> confirm -> save -> return to list... that's a lot of backtrack state to maintain in the url/submitted form. Say I'm at save and need to direct back to the user's list page. I need to know the qualifier applied to the list, the list batch size, the list batch index, the list sort orderings, and the authenticated user if any. Hard, lots of work, but probably not impossible. By the time you get half way through implementing it, a fat stateful server with D2W isn't looking so bad.
>
> Or maybe I edit a relationship and create a new unsaved object related to the list object. I can't hand that new EO to the confirm page except by temp global id. If I restart the app on the confirm page... doom! :-)
>
> Stateless server is the new hotness and sounds great, but it becomes a lot of work very quickly. I'm sure ERRest helps a lot, but short of some unreleased fat client like Gianduia, you still end up having to invent all the state management on the client yourself AFAIK.
>
> [This is where Pascal points me to his newly released Dojo awesomeness or something to prove me wrong ;-)]
>
> Ramsey
>
>
> On Dec 2, 2011, at 9:06 AM, Pascal Robert wrote:
>
>>
>> Le 2011-12-02 à 11:03, Jean-Francois Veillette a écrit :
>>
>>>> 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 !
>>
>> Or you use ERRest HTML routing :-)
>>
>>>
>>>> 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@hidden> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden