[Seaside] REST, bookmarkable URL's

Avi Bryant seaside@lists.squeakfoundation.org
Thu, 02 Jan 2003 14:46:39 -0800 (PST)


On 2 Jan 2003, Cees de Groot wrote:

> Avi Bryant <avi@beta4.com> said:
> >[...] 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.
> >
> Cool. So it seems it's a documentation issue again ;-)

Indeed.  Contributions to docs are welcome ;).

I should point out, though, that using #nextKey: is not yet as simple as
it should be, which is one of the reasons I haven't documented it - it's
still an evolving feature.  The problem is where you set it - there's no
easy hook where a component could change the url right before it's
displayed for the first time.  So you have to set it from the
calling component (which makes sense in some cases - the caller might know
the context better than the callee, eg, whether you're in the middle of an
"edit" or a "create", which often use the same component), right before
the #call:.

> I hacked VW's WTK to support session id's in the URL (don't like cookies - too
> many problems with broken proxies). I use something like
> '@=c=@DFLKJSLFKJSDLFKJ' as a path element, so I split the URL and check
> whether any element has '@=c=@' - this is decoded, the rest is joined together
> and used as the location to work with.

Well, Seaside right now uses a ";DASDASD" appended to the rest of the URL,
which works pretty well for picking out the session key. And right now the
rest of the url, after the application name, is all treated as a
continuation key - which is why you can set it to something like "n/8".
That actually pulls out the continuation stored under 'n/8' and runs it.
However, if you want some of that to be a static prefix, and some of it to
be a (probably numeric) contiuation key, we'll have to come up with a way
to distinguish the two.

Avi