John Siracusa <[EMAIL PROTECTED]> wrote: >On 6/12/02 12:17 PM, Perrin Harkins wrote: >> James G Smith wrote: >>> The nice thing about the context then is that customers can have >>> multiple ones for multiple windows and they can have more than they >>> have windows. >> >> How do you tie a context to a window? I don't see any reliable way to >> do it. The only way to maintain state for a window (as opposed to >> global state for a session) is to pass ALL the state data on every link. > >Nah, you could just shove a context param into all forms and links on each >page, and store the actually (possibly large) context server-side, keyed by >context id (and session id, see below) > > <a href="/foo/bar?context_id=2">...</a> > ... > <input type="hidden" name="context_id" value="2"> > ... > >Note the tiny context id. If you lookup contexts using both the context id >and the (cookie-stored) session id, you can get really short context ids :) >Just an idea...
I haven't worked this part out yet, though that is one way I thought of. This is similar to how Twig handles contexts. Another way I was thinking about was making it part of the URL. For example: https://x.y.z.edu/contextid/rest/of/url.html The session would be with a cookie. This would allow cutting and pasting of URLs for help tickets and such while preserving the context. This would also make coding easier by using relative URLs. Of course, this has all the problems of storing the session ID in the URL in the same manner. We might also have to look for links that open a new browser window and give them a new context. I'm still working out the details. I could be really evil and make the URLs 32-hex strings that map to a context and URL combination >:) Obfuscated web site with no hope of deep linking.... -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
