[Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list

Avi Bryant avi@beta4.com
Tue, 16 Apr 2002 22:36:20 -0700 (PDT)


On 16 Apr 2002, Jimmie Houchin wrote:

> I believe that is an inaccurate and simplistic view of how Zope
> operates. Zope serves objects out of its object database. Some of those
> objects may be compelete html chunks, others are not. The links as you
> say within Zope, are not necessarily to other pages but are references
> to objects within its database.

I don't know Zope well enough to directly comment.  However,
links in Seaside can be seen in much the same way: they are references to
objects.  That is, in general, what a url is: an external way of
addressing a particular resource.  The trouble with meaningful URLs is
that you have to give a meaningful name to each object you want to be able
to refer to.  This becomes rather limiting: in your code, most of your
objects do not have meaningful names, but merely have (meaningless,
numeric) memory addresses.  If you don't force each object referenced by a
URL to be named, you have a lot of flexibility in which objects and how
many objects can be directly referenced by URLs.  I think Seaside makes
good use of this flexibility.

> If you did Amazon in Seaside is it a web app?
> Is a page on a specific book web site or web app?
> Is it an entry point to a web app?
> Would it be bookmarkable in Seaside?

Just to be clear, there's nothing un-bookmarkable about Seaside URLs.
All you have to do is make sure the session stays around for as long as
you want that bookmark to be valid.  Disk space is cheap: if you want
people to be able to save the exact state of their session for a month,
I don't see that as a problem.

> Are actions undone by going back to previous points in viewing?
> ie: Is state reverted?

State is not reverted.  A large part of state is stored, however.  If you
go back to an earlier page, you are going back to a copy of the page
object as it was when that page was generated.  You can use the #freezeTo:
method to control exactly how deeply this copy is made.  For example, the
calculator example preserves the entire calculation stack.  By default, a
simple shallow copy of the page component is saved.

> When I click on the back button does Seaside re-serve the page?
> Would it be just like it was when I was there before?

If you click the back button and hit reload, the page will be as it was
before, unless it relies on some more global state (say, a database, or
the current time of day), in which case that will be seen up to date.

> Do you have an example of where this feature has value?

> With Amazon via Seaside, I do a search, get a list of books.
> >From that list of books I click on one and proceed forward and add to
> shopping cart. I then click back multiple times to get to my list to
> browse other books.
>
> How does #isolate affect that situation?
> Do I lose going back or lose the add transaction?

Play with the store example that comes with Seaside.  It makes the
following choice: within a single purchase, the back button does affect
the shopping cart - that is, if you add something to your cart, then hit
back, then add something else, the first thing you added is no longer in
your cart.  One you finish that purchase (click "Done Shopping"), the
contents of that cart become fixed, in that none of those pages are
accessible any more (and the total tally of purchases made can't be
affected).

This model probably wouldn't make sense for Amazon: you'd want the cart to
persist through the entire session, back button or no.  You'd probably
want the cart stored in the Session object, which is never copied, rather
than the Component objects, which are.  However, this behavior might make
sense in a point of sale situation: add this item, oops, wrong item, hit
back, add a different one.

Cheers,
Avi