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

[Jimmie Houchin]

On Tue, 2002-04-16 at 13:04, Julian Fitzell wrote:
> Jimmie Houchin wrote:
[snip] 
> The reason seaside has ugly URLs as compared to Zope is that in Zope you 
> create a complete html chunk and manually put in links to other pages by 
> name. Seaside is much more dynamic than that.  A link is given an id, 
> and the action performed by that link can be changed through bindings. 
> So Seaside needs to generate a URL that uniquely identifies a specific 
> action triggered by a link on a specific instance of a page view.  The 
> URLs aren't that ugly, really, they just have a few numbers that 
> uniquely identify exactly what point you are at in the application.

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. Some objects have a view and are
viewable, some are not. Objects may be any number of things. Some maybe
snippets of a script or html, others images or other binary data. I do
not believe that Seaside is necessarily more dynamic than Zope or that
Seaside can build apps that Zope can't. Not slamming Seaside, I don't
know it well enough. Just trying to clarify Zope.

> > URLs which are bookmarkable and emailable are a valuable feature. One
> > that I greatly desire. I don't think that dynamism, et al, require
> > giving up such. (From my naive point of view).
> 
> Although I agree that websites with bookmarkable URLs are nice I'm not 
> sure I agree that the same is true of web applications, which is what 
> seaside is designed for.  It makes no more sense for me to bookmark the 
> point at which I was half done adding a comment to bug 317 in a seaside 
> bug tracker than it does for me to bookmark the point just before I 
> typed "foo" on page 37 of some document in Word.
> 
> What you need to bookmark is applications, not specific runs of an 
> application and that is simple to do since you can enter an application 
> with a URL as simple as http://foo.com/seaside/bar.  You can create as 
> many applications as you want so if you have different points in your 
> application that you want the user to be able to start at you can create 
> simple wrapper components that start in the right place, create a new 
> application and voila.

I think what is a website and what is a web application is somewhat
ambiguous and deceiving. The end user doesn't necessarily know which is
which in practice. They simple have visited a page and would like to
either bookmark it or email the URL. This should be reasonably
manageable.

ECommerce site, web sites or web apps?
Amazon web site or web app?
Mixture, combination?

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?


> > Thanks for any help at understanding Seasides point of view on this both
> > technically and philosophically. :)
> > 
> > Jimmie Houchin
> 
> So while I also hate websites with ugly URLs in theory, I really can't 
> think of a solution that allows the server to uniquely identify where in 
> time the user is in an application.  Remember that Seaside allows 
> backtracking using the browser's back button too, so you can't just 
> remember the current state of the application like you might in a PHP 
> session variable, you actually need to know, when a user clicks on a 
> link, whether they're clicking on it on the current page view or whether 
> they've hit back 10 times and are clicking on it on a page view before 
> having made some other modification to the state.

I don't know if understand the above accurately.

In your example are we talking about an identical link on two different
pages or possibly the same page just at a different point in their
viewing history?

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

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?
ie: Would the state be as it was previously or affected by the page
forward of it in history?

Do you have an example of where this feature has value?
Just read Tutorial part 2. Still processing. :)

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?

> Hope that clears things up a little,

Well see? :)
Unfortunately I am not very Smalltalk proficient yet.

Thanks.

Jimmie Houchin