[Seaside] Seaside and REST

[Nevin Pratt]

I know that Seaside and REST have been discussed before.  For example, 
on 4/8/05, Cees wrote the following:

> I've been thinking for some time that it should be possible, somehow, 
> to merge HttpView and Seaside into a 'seamless' web application. 
> HttpView could do REST-style 'static' stuff, Seaside would pick up 
> where more interaction is needed. Both support essentially the same 
> style of HTML generation, so that shouldn't be a large chasm to cross.
>
> For example, a Wiki would use HV to display pages, as soon as you 
> press the Edit button you go into a Seaside session (of course, the 
> trick is that the next time you press the Edit button, you may want to 
> go into the *same* Seaside session - stuff like that needs to be 
> checked when integrating them). This is a very simple example, but I 
> think it's one of the things necessary to optimize things. Kicking off 
> the whole Seaside machinery for essentially static pages is just a bit 
> too much, I think. 

The problem with Cees' approach is that it is Squeak-specific.  What 
about folks that want to try the GemStone/Seaside version?  That is what 
I would like to do.

Many years ago I hand-spun my own approach for RESTful URL's in 
Squeak.   My approach involved  inserting an element in the URL, like this:

   http://www.bountifulbaby.com/seaside/seasideappentrypoint/selector

Of course, 'seasideappentrypoint' is simply the entry point defined in 
the Seaside config page, and selector is simply a method name-- it means 
execute that method on the entry point app component.  This allows 
relatively arbitrary app entry points, like this:

   http://www.bountifulbaby.com/seaside/index/home (executes the #home 
method of the component, which has been written to cause it to show the 
home page)
                         or
   http://www.bountifulbaby.com/seaside/index/aboutus (executes the 
#aboutus method of the component, which has been written to cause it to 
show the "About Us" page)

So you can see, I can actually start the app at an arbitrary point, by 
specifying the method name to execute as part of the URL (security is 
handled by requiring that the method name be present in the component 
under a specific and known method category name-- this stops people from 
being able to execute completely arbitrary methods via the URL, because 
the method to execute must be present in a specific method category).

This approach also gives me bookmarkable URL's, because, for example, a 
URL like this:

   
http://www.bountifulbaby.com/seaside/index/aboutus/@XxPZklzXRHVKPvCA/zHJLMslu

Converts back to this once the session expires:

   http://www.bountifulbaby.com/seaside/index/aboutus

And they will both show the "About Us" page.  So, if somebody bookmarked 
the first one while running the app, the bookmark would work just fine, 
even after the session expired.

The problem with my approach, though, is that it required me to muck 
around with some of the Seaside base code.  And this, in turn, has 
locked me into an older version of Seaside (unless I also port my mods).

Now that I am considering GemStone/Seaside, I would like to redo my 
ideas for bookmarkable URL's, and come up with something that fits in 
better with the existing Seaside framework.

Surely there must be some advances within the newer versions of Seaside 
which make all of my older hacks unnecessary?  What are they?

Nevin




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070502/db0accf6/attachment.htm