[Seaside] REST, bookmarkable URL's

[Avi Bryant]

On 2 Jan 2003, Cees de Groot wrote:

> <idea>
> Seaside interprets the opaque info, and if it points to a session that's gone,
> it uses the mount path to redirect to the 'entry page' of the component.
> </idea>
>
> So I have a domain 'resource'. I 'mount' it at '/domain/foobar.com'. Now, when
> I go to '/domain/foobar.com', Seaside redirects me to
> '/domain/foobar.com?sess=SDFKJNEWIUFSKDFHksfZXC&step=1'. When I use that thing
> half a year later, I get redirected to the same point, but with a fresh
> session, and possibly a password box.
>
> I think that would combine best of both worlds.

Yes.  I've been trying to move towards being able to do something very
much like this.  The redirection to a new session already happens, and
there's general support in the form of WASession>>unknownRequest: for
defining custom URL schemes - just override it in your session class, pull
the url out of the request and do what you like from there.  If you don't
know what to do with it, pass the request on to the super method.

The more interesting part is how you get the url to be /domain/foobar.com
in the first place, so that people can bookmark it.  Session
has a #nextKey: method, which you can use to effectively set the
current url.  For example, try this - add

 session nextKey: 'n/', self count asString

to the end of WACounter>>increment.  Now, when you increment the counter
to 8, for example, the url will be

/counter/n/8;somesessionid

and if you used cookies for session ids, it would simply be

/counter/n/8

All of the links on this page will still be unique, meaningless numbers,
but everytime you choose one you'll be redirected back to the more
REST-style url.

The (possible) disadvantage of doing this is that if you had a series of
pages that all used /domain/foobar.com as their url, the browser would
only keep the most recent of those in its cache, and you wouldn't be able
to backtrack to the others.  If you used slightly more specific urls
(/domain/foobar.com/zone/edit) this probably wouldn't be an issue (and
might even be desired behavior).

What Cees is describing, with a constant prefix that is followed by a
numeric continuation id, isn't directly supported yet, but shouldn't be
too hard either.  The only annoying part is being able to parse the url -
how do you know how much of it is prefix and how much is the continuation
key...