[Seaside] Seaside and REST

[Michael Roberts]

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