On Mon, Apr 11, 2011 at 2:09 PM, Stephan Beal <[email protected]> wrote: > On Sat, Apr 9, 2011 at 4:43 AM, Stephan Beal <[email protected]> wrote: >> Are there areas of fossil's ui which would benefit from having sessions? > > To answer my own question... i just coincidentally came across a good use > case for this... > When viewing the timeline using custom options (e.g. specific date and count > parameters), then leaving the timeline (e.g., to log in so that the timeline > links are visible), "it would be cool" if the next click on the timeline > line restored my previous state. With persistent sessions, that type of > thing would be possible.
This specific case could be handled in at least 4 ways: 1. The login mechanism could use the Referer header in the request sent when the Login link is clicked. Of course, the login mechanism would then have to somehow preserve this information for when the login is completed. 2. A 'return' parameter could be added to the Login link. The value of this parameter would be the URL os the current page, or, in the case of the Login page, the value from the return parameter passed when Login was clicked. 3. A 'current URL' cookie could be set by all pages except the login page. Then when the login is completed, the value of this cookie would be used.. 4. The Login link could open a pop-up to perform the login. The current page would be left alone, but the login cookie would be updated. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
