[Seaside] Seaside and REST

[Todd Blanchard]

Definitely need both.  

WebObjects had regular stateful urls but they also added DirectActions (stateless urls - minimal handling) for doing RESTful stuff.
Seaside needs something similar.

 
On Wednesday, May 02, 2007, at 10:06AM, "Nevin Pratt" <nevin at bountifulbaby.com> wrote:
>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
>
>
>
>
>