On 2011-12-02, at 10:21 AM, Ramsey Gurley wrote:
>
> On Dec 2, 2011, at 11:07 AM, Chuck Hill wrote:
>
>>
>> On 2011-12-02, at 7:32 AM, Ramsey Gurley wrote:
>>
>>> I have a framework that is designed to serialize the session automatically,
>>> save it to the database, and use distributed sess
On Dec 2, 2011, at 11:07 AM, Chuck Hill wrote:
>
> On 2011-12-02, at 7:32 AM, Ramsey Gurley wrote:
>
>> I have a framework that is designed to serialize the session automatically,
>> save it to the database, and use distributed session storage. Theoretically,
>> you could set the session to a
On 2011-12-02, at 7:32 AM, Ramsey Gurley wrote:
> I have a framework that is designed to serialize the session automatically,
> save it to the database, and use distributed session storage. Theoretically,
> you could set the session to almost never expire, allowing an almost
> permanent login
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
Thanks Guys for the helpful comments.
I think I was a bit misunderstood, I got my answer though :).
Actually, my application has a public website that is session less and relies
on cookies to identify users using direct actions only. In this case, it's easy
to keep users logged in.
However, wh
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.
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
> 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. Li
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 te
I have a framework that is designed to serialize the session automatically,
save it to the database, and use distributed session storage. Theoretically,
you could set the session to almost never expire, allowing an almost permanent
login like this.
It just doesn't work in practice, because seri
Hi Mahdi,
The session is not just a cookie. It is a reference to many objects stored
in RAM for one user. It's what allows a web application to "remember" what
a user is doing. It can eat up a lot of resources but is very convenient.
That thing you are currently storing in a cookie is just a "k
I never saw a web app that do that, unless you go stateless.
> 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 behaviou
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 a
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 a
écrit :
> Hi,
>
> I'd like to do something but I am not sure whether it's possible.
>
> I have a WO applica
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
applicatio
15 matches
Mail list logo
