[Seaside] Seaside and REST

Todd Blanchard tblanchard at mac.com
Thu May 3 02:41:50 UTC 2007

There are a couple cases.

Bookmarkable entry points is one.  Here the idea is to allow the user  
to jump right to a particular page in the app - probably with a  
particular bit of state (which implies you need to add keys to the  
url that indicate what state this is).  This case involves creating a  

The other is when you want to publish something at a url - might be  
expecting fairly high traffic, and do not want to incur a session  

In general, I have tried to find the point at which sessions are  
created or looked up and confess I haven't been able to find it.  I  
would like to intercept that point and either always find the same  
session or simply skip the session creation.  I'm not too clear how  
to do that.

The simple example is a blog.  Seaside is great for editing the blog  
- lousy if your blog were to get digged.  At present I'd probably do   
the read-only part of the blog using HttpView and the editing part  
using seaside.

On May 2, 2007, at 4:44 PM, Michael Roberts wrote:

> ok, so if you see my other post I'm clearly missing something.
> I don't dispute that we might need some new features, but I don't  
> see that what you have said is an answer to Nevin's question.  For  
> me you've answered a different question.
> Whether Seaside's REST support is stateless or minimal or not does  
> not prevent the current API from doing bookmarking.  It sounds like  
> you have a different goal?
> Thanks,
> Mike
> On 2 May 2007, at 21:31, Todd Blanchard wrote:
>> 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
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list