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

Marcel Weiher marcel@metaobject.com
Wed, 17 Apr 2002 18:41:53 +0200


On Wednesday, April 17, 2002, at 04:27  Uhr, Julian Fitzell wrote:

> Marcel Weiher wrote:

>> Yes, making the page essentially stateless.  Many pages have a very 
>> limited amount of state that isn't much harder to encode into the URL 
>> than a session.  Let's say you have a single object that contains the 
>> state for a page.  Just use key-value coding to encode that object as 
>> URL-parameters, encoding the page class itself in the path.  The 
>> generic logic then unarchives this object from the URL parameters, 
>> sets up the page with that object and starts executing.
>
> There are certainly cases where this can be done.

Yes.  What we discovered during the development of NPS ( a content 
management system,  www.infopark.com ) is that the cases are *much* more 
common than we had originally thought.

>  If all the state is propagated to a DB or if the web application is 
> read-only it is far more likely that you might be able to get away with 
> this.

My contention is that you can get away with this a lot more than you 
think, and get a much better user-experience as a result.  Once again, 
this is a result that we hadn't expected, but found to be true.

> *But*, one of the benefits of Seaside (as far as I'm concerned) is that 
> the user can write it without worrying about what can be encoded in a 
> URL.  If I'm writing an application to do something with widgets, I 
> want to use widget classes in all my code... I don't want to have to 
> use id strings so that there is something that can be written out to a 
> URL.

Hmm, why should automatic mechanisms stop working just because you're 
encoding state in the URL?  I realize that this perception is common, 
because the 'comfortable' web-development tools (like WebObjects, for 
example) are primarily session-based and don't implement running 
session-less particularly well.

Anyway, the issue isn't really how much you can encode, more typically 
is the case that you have to rethink your app a little from a typical 
procedural mind-set to a more pure functional mind-set.  This is not 
necessarily a bad thing.

> Also, I want the user to be able to hit the back button and not screw 
> everything up.

When you're stateless, the back-button ceases to be a problem.

>   Users expect to be able to use the back button when browsing the web 
> and I don't want things to get screwed up when they do.  To handle this 
> smoothly, seaside needs to know the complete page view history for a 
> session (or at least however much of it you decide to keep around).  
> You can't possibly encode all that information in a URL.

You don't need to do that when you're stateless.  In fact, the back 
button was one of the incentives we had for moving our app towards 
statelessness.

> So while I agree nice pretty meaningful URLs that you can logically 
> return to at any point would be nice, I really don't think there's a 
> way to achieve that and still have the benefits of seaside.

I disagree.  Having built a web-framework and applications using that 
framework, I am pretty certain that it can be done.  The framework 
wasn't as comfortable as Seaside (or WO for that matter), but the issues 
were largely orthogonal.

>   And to me, the benefits are worth the sacrifice.

You don't have to sacrifice.

> Also, as avi pointed out, as long as you cache the sessions, there is 
> nothing to prevent someone from bookmarking a seaside page and 
> returning to it later.

Only with unlimited storage.

>   And because you can hit back and then branch off again, you can go to 
> the bookmarked page and carry on as if you'd never done so before.  
> Assuming that is logical in the context of a particular application.  
> This is another advantage.  If the context of the application dictates 
> that it doesn't make sense to be at this place more than once, then the 
> developer would have put it in a transaction and if you went to that 
> bookmark you would be redirected to wherever you last were in the 
> application.

Good you mention transactions, because the system we had developed also 
had what we call micro-transactions:  when actual significant edits were 
to be performed, a micro-transaction would be created that would 
typically persist for 2-3 page-views.  This would also not be 
repeatable, with the statlessness around it not being affected.

> Seaside URLs are:
> - short
> - not particularly ugly (they don't have 30 ?foo=bar&baz=bar style 
> parameters on the end, which I really don't think makes for cleaner 
> URLs)

I don't consider the visual aesthetics of URLs that much of a concern.

> - very much meaningful (just not to a human)

Stateless URLs are also meaningful and can even be parsed/created by 
humans.

> - bookmarkable (when appropriate and logical to do so)

Not really.

> That said, Seaside is a web application framework, not a website 
> framework.

I don't believe this is a meaningful distinction in this context.  It is 
an easy trap to fall into because that is how most of the (visible) 
world looks, but there is actually nothing inherent about it.

>  If having one URL for each page is what you want (and I know this 
> isn't what you were saying Marcel, I'm just responding to other 
> messages in this thread) then seaside is just not your solution.  If 
> you want to write a web app and you don't want to have to even *think* 
> about URLs, CGI parameters, URL parsing, session persistance, etc, etc, 
> etc then seaside might do it for you (it certainly does for me).

The interesting thing is that these issues are *orthogonal*.

> And yes, there is a very fuzzy line between what constitutes a web app 
> and what does not.

Exactly.  We found that the line went straight through our app, and my 
experience so far strongly suggests that the same is true for most web 
applications.

>  To me, the difference is that a web site is something you go to to get 
> information and therefore may want to return to the same page to get 
> the same information.  A web app is something that you run to get 
> something done.

Sorry, I don't see a difference.  Getting something usually involves 
going to some page, looking at lots of information and then changing a 
little bit of it.  As a matter of fact, you're going to have a difficult 
changing a lot of information via the web, the bandwidth of the UI is 
pretty limited.

>  And since you don't want to do the same thing again, you don't need to 
> return to where you were last week.  You just connect to the 
> application again and do something else when you need to.

Once again, we found that this wasn't true.  Different people had 
different areas of the app that they had to deal with, and forcing a 
sequence of operations was not an enhancment to their user-experience.

> That said, I have wondered about having a mechanism to initialize an 
> application with parameters in the URL.  That way you could have links 
> on a web page that configured the app for a particular skin, or opened 
> it to view a particular object (based on its id in a table), or allowed 
> you to specify a string to search for, or...

This is actually exactly what I am saying, except that you re-initialize 
the app as much as possible...

>  All of this can be accomplished by having multiple applications 
> defined or by making your entry page part of the application but 
> allowing this feature might make it easier to integrate smaller seaside 
> apps into non-seaside web pages.  Making it easier to have a mixture of 
> seaside and non-seaside content would help prevent people from feeling 
> like seaside needs to accomplish all their web needs, IMO.  Thoughts?

Exactly, the boundary is fluid, and the it should be easy to cross the 
boundary from completey static to stateless to stateful.

Marcel


--
Marcel Weiher				Metaobject Software Technologies
marcel@metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.