[Lift] Re: expired sessions and log in

[Charles F. Munat]

Well, regarding these sorts of pages, I'd like to make it possible for 
multiple users to work on the same data, seeing each other's changes 
immediately. For that, I'm thinking Comet and editable tables.

So I'm looking at the table of Events, e.g., which has rows with the 
name of the event, a URI for the event page, dates and times, etc.

To change the name of the event, I click on that cell in the table, 
which responds be becoming an editable text box (or maybe it is already 
an editable text box, although my experiments with large tables of form 
inputs has not been very successful -- browsers often choke on them).

I change the name of the event and either tab out of it or click 
somewhere else on the page, and the page automatically updates that 
attribute for that event in the database. This would be live updating.

If anyone else is viewing that event's data, the changes are 
automatically pushed to them.

On my end, I get an undo arrow in the field, which I can click to undo. 
If I do undo it, I get a redo arrow. Does this make sense? (How does 
this work with multiple simultaneous editors?)

If I don't want to work on this data live, then I tell the page to turn 
off live updates. Then every change I make creates a temporary object 
(or maybe just a list of changes). At the end of the session I can save 
these changes and their undo stack so I can work on them more later, 
merge them into the real data (also an undoable step), or delete them. 
Other users could be working on the same data simultaneously.

It's really an online, multiple-user, versioning system.

That's my fantasy. I've done similar things in other languages, but 
never to the full extent I'd like to.

Oh, and yes, I absolutely need an audit log, which is why I like to keep 
all changes permanently. Space is cheap.

Chas.

David Pollak wrote:
> 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://

[Lift] Re: expired sessions and log in

[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

[TylerWeir]

Charles, can you implement something like the auto-saving feature of
GoogleDocs/GMail?

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



--~--~-~--~~~---~--~~
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

[Charles F. Munat]

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

--~--~-~--~~~---~--~~
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

[David Pollak]

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


--~--~-~--~~~---~--~~
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

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

[Charles F. Munat]

This is an interesting idea. I'll think about it.

Thanks!

Chas.

TylerWeir wrote:
> Charles, can you implement something like the auto-saving feature of
> GoogleDocs/GMail?
> 
> 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
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
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

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

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

[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

[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

[Tim Perrett]

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.


--~--~-~--~~~---~--~~
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

[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
-~--~~~~--~~--~--~---