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

[Julian Fitzell]

Marcel Weiher wrote:
> 
> On Tuesday, April 16, 2002, at 08:57  Uhr, Cees de Groot wrote:
> 
>> Cees de Groot <cg@cdegroot.com> said:
>>
>>> I've got some very ugly URLs between my bookmarks. I couldn't care less,
>>> because the software shows the title of the page, not the URL itself.
>>>
>> I was a bit too quick here, completely overlooked the fact that these 
>> ugly
>> URL's tend to have session identifiers in them and thus are invalid
>> two weeks later. Oops. However, this can be dealt with gracefully in a 
>> lot of
>> cases by the server - simply create a new session and redirect the 
>> user. Or
>> encrypt everything necessary for the session in the ugly URL and 
>> forget about
>> keeping it around server-side, so that it effectively never expires.
> 
> 
> 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.  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.

*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.

Also, I want the user to be able to hit the back button and not screw 
everything up.  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.

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.  And to me, the 
benefits are worth the 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.  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.

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)
- very much meaningful (just not to a human)
- bookmarkable (when appropriate and logical to do so)

That said, Seaside is a web application framework, not a website 
framework.  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).

And yes, there is a very fuzzy line between what constitutes a web app 
and what does not.  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.  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.

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...  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?

Julian


-- 
julian@beta4.com
Beta4 Productions (http://www.beta4.com)