[Lift] Re: expired sessions and log in

2008-10-06 Thread David Pollak
Charles,

Having a persisted undo/redo log also implies an audit log... which is very
cool.

Okay... I think we have to roll these concepts into the Record/Field stuff
so that it's all nice and automagic.

What are your other requirements/fantasies?

Thanks,

David

On Mon, Oct 6, 2008 at 12:23 AM, Charles F. Munat [EMAIL PROTECTED] wrote:


 Yeah, I've thought about this before in the context of a sort of
 infinite undo function. As you make changes in your form, they are saved
 to the database. Then you can, when you navigate away, choose whether to
 save them as temp edits, publish them, or delete them. If you save them
 as temporary edits, you can come back and pick up where you left off,
 with the undo stack intact. Then you can back up through the history.

 I've thought for a long time that as many things as possible should be
 versioned (like operating systems) so that there is always an infinite
 undo/redo. Since I'm building websites that are really small Content
 Management Systems, this really appeals to me.

 For example, if you were editing page text, it would be nice to be able
 to start by creating a working copy of the current page. Then you could
 make a series of undo-able edits to the page, stopping and returning to
 it whenever you wanted to. Finally, you could either publish the
 finished page (i.e. make it public as a new page or replacing a current
 page), or delete it.

 What you're talking about seems like a good basis for something like that.

 Chas.

 David Pollak wrote:
 
 
  TylerWeir wrote:
  Charles, can you implement something like the auto-saving feature of
  GoogleDocs/GMail?
 
 
  I really like this idea.  I'm going to noodle on a way to make it a part
  of Lift... basically an form that periodically serializes from browser
  to server and allows the serialized data to be placed in a persistent
 store.
 
  This may be annoying based on whether or not it's permissible to have
  incomplete/imperfect values.
 
  But if the user can have a draft status of the form, then simply save
  the form data, mark it as jank and when they come back to edit and
  submit you can validate/sanitize.
 
  Hope that helps.
 
  Ty
 
 
 
 
 
 
  

 



-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Martin Ellis

On Sun, Oct 5, 2008 at 7:28 PM, Charles F. Munat [EMAIL PROTECTED] wrote:

 I'm working on an app in which users may spend significant time editing
 a form before submitting it. It's possible during this time that their
 session could time out. My concern is that they might submit a long
 edit, discover that their session has timed out, log in, and lose the
 edit. (They can probably back up and resubmit, but these are not very
 savvy users.)

 I'd like it to remember their update, hold it until they log back in,
 then send them a prompt to ask if they want to:

 a) complete the update,
 b) cancel the update,
 c) return to the edit form (with their recent edits included, though not
 yet saved).

 Any ideas for how to go about this?

I guess it's still true that:

  The best way to deal with the particular situation (browser
  open, don't want the session to disappear), is to put a hidden
  CometActor on the page that does nothing other than keep
  the session alive. - David Pollack
  
http://groups.google.com/group/liftweb/browse_thread/thread/e98f2f75cc4461e4/10a16b586e879b11


Martin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread David Pollak
See net.liftweb.mapper.ProtoExtendedSession

This does not address the issue of the opaque identifiers used to map from
form fields to functions.

On Sun, Oct 5, 2008 at 1:02 PM, Tim Perrett [EMAIL PROTECTED] wrote:


 Indeed - me and Ty were just talking about this incidentally, and
 there is no easy way to implement this.
 Its a bit messy granted, but sure, the comet actor appears to be the
 only way to do it.


 



-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Charles F. Munat

I don't want to keep the session alive. I know how to do that. I want it 
to time out and force them to log in again. I just want it to remember 
what they were doing. Does that make sense?

Thanks,
Chas.

Martin Ellis wrote:
 On Sun, Oct 5, 2008 at 7:28 PM, Charles F. Munat [EMAIL PROTECTED] wrote:
 I'm working on an app in which users may spend significant time editing
 a form before submitting it. It's possible during this time that their
 session could time out. My concern is that they might submit a long
 edit, discover that their session has timed out, log in, and lose the
 edit. (They can probably back up and resubmit, but these are not very
 savvy users.)

 I'd like it to remember their update, hold it until they log back in,
 then send them a prompt to ask if they want to:

 a) complete the update,
 b) cancel the update,
 c) return to the edit form (with their recent edits included, though not
 yet saved).

 Any ideas for how to go about this?
 
 I guess it's still true that:
 
   The best way to deal with the particular situation (browser
   open, don't want the session to disappear), is to put a hidden
   CometActor on the page that does nothing other than keep
   the session alive. - David Pollack
   
 http://groups.google.com/group/liftweb/browse_thread/thread/e98f2f75cc4461e4/10a16b586e879b11
 
 
 Martin
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread David Pollak
On Sun, Oct 5, 2008 at 3:57 PM, Charles F. Munat [EMAIL PROTECTED] wrote:


 So if I understand you correctly, I would keep the session open
 indefinitely, but implement a time-out that forced the user to log in
 again after a certain period of inactivity?

 I see how that way I could maintain the update on the server while
 handling the log in -- is this the recommended method?

 When the session expires, are continuations lost? I guess I really need
 to dig into this code a bit more.


I think you're going to have to go back to traditional methods of setting
up your form with stable field names and using S.param to decode the
incoming POST. :-(




 Chas.

 David Pollak wrote:
  See net.liftweb.mapper.ProtoExtendedSession
 
  This does not address the issue of the opaque identifiers used to map
  from form fields to functions.
 
  On Sun, Oct 5, 2008 at 1:02 PM, Tim Perrett [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] wrote:
 
 
  Indeed - me and Ty were just talking about this incidentally, and
  there is no easy way to implement this.
  Its a bit messy granted, but sure, the comet actor appears to be the
  only way to do it.
 
 
 
 
 
 
  --
  Lift, the simply functional web framework http://liftweb.net
  Collaborative Task Management http://much4.us
  Follow me: http://twitter.com/dpp
  Git some: http://github.com/dpp
 
  

 



-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Charles F. Munat

So if I understand you correctly, I would keep the session open 
indefinitely, but implement a time-out that forced the user to log in 
again after a certain period of inactivity?

I see how that way I could maintain the update on the server while 
handling the log in -- is this the recommended method?

When the session expires, are continuations lost? I guess I really need 
to dig into this code a bit more.

Chas.

David Pollak wrote:
 See net.liftweb.mapper.ProtoExtendedSession
 
 This does not address the issue of the opaque identifiers used to map 
 from form fields to functions.
 
 On Sun, Oct 5, 2008 at 1:02 PM, Tim Perrett [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 
 Indeed - me and Ty were just talking about this incidentally, and
 there is no easy way to implement this.
 Its a bit messy granted, but sure, the comet actor appears to be the
 only way to do it.
 
 
 
 
 
 
 -- 
 Lift, the simply functional web framework http://liftweb.net
 Collaborative Task Management http://much4.us
 Follow me: http://twitter.com/dpp
 Git some: http://github.com/dpp
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Charles F. Munat

Hmmm. That's an idea and I'm not averse to it. I'll think about it some 
more.

Thanks,
Chas.

David Pollak wrote:
 
 
 On Sun, Oct 5, 2008 at 3:57 PM, Charles F. Munat [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:
 
 
 So if I understand you correctly, I would keep the session open
 indefinitely, but implement a time-out that forced the user to log in
 again after a certain period of inactivity?
 
 I see how that way I could maintain the update on the server while
 handling the log in -- is this the recommended method?
 
 When the session expires, are continuations lost? I guess I really need
 to dig into this code a bit more.
 
 
 I think you're going to have to go back to traditional methods of 
 setting up your form with stable field names and using S.param to decode 
 the incoming POST. :-(
  
 
 
 
 Chas.
 
 David Pollak wrote:
   See net.liftweb.mapper.ProtoExtendedSession
  
   This does not address the issue of the opaque identifiers used to map
   from form fields to functions.
  
   On Sun, Oct 5, 2008 at 1:02 PM, Tim Perrett [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
  
  
   Indeed - me and Ty were just talking about this incidentally, and
   there is no easy way to implement this.
   Its a bit messy granted, but sure, the comet actor appears to
 be the
   only way to do it.
  
  
  
  
  
  
   --
   Lift, the simply functional web framework http://liftweb.net
   Collaborative Task Management http://much4.us
   Follow me: http://twitter.com/dpp
   Git some: http://github.com/dpp
  
   
 
 
 
 
 
 -- 
 Lift, the simply functional web framework http://liftweb.net
 Collaborative Task Management http://much4.us
 Follow me: http://twitter.com/dpp
 Git some: http://github.com/dpp
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
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
-~--~~~~--~~--~--~---