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 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/probert%40macti.ca
> 
> This email sent to [email protected]

 _______________________________________________
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]

Reply via email to