Seaside and REST

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

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

> 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"  
> <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>
>
> From my point of view the various discussion threads have had
> different goals.
>
> My take on Seaside's REST support (only from my apps, of course) is
> two fold.  1) It works ok.  2) If enough people used it the API could
> be improved so that you didn't have to do quite so much work to get it
> going.  From my point of view Seaside's REST support is not lacking
> much it's just not handed to you on a plate.  We have seen lots of
> Seaside's API evolve over time and become much more convenient.  I
> just think that there is not enough interest in this area for the
> people actually committing the code to the repository.  For me REST is
> so small in the Seaside life-cycle.  It let's you define start and end
> points but says nothing about the in-between.  I imagine this is
> because once you get it going you move onto something much more
> interesting.  Like the dynamic stuff, which is why we are here after all.
>
> I'm not trying to be disingenuous about REST, HV or anything else.
> It's just that I have all sorts of challenges with Seaside programming
> but how to start the app from a bookmark is not one of them ;-)  Now
> maybe starting an app from a bookmark is not REST, per se... but just
> another Seaside practicality.
>
>
> Seaside gives you 1) a mechanism for starting your app from a well
> known URL 2) a way of adding information into the URL so you can
> generate such a starting point.
>
> I think I wrote a wee app for a separate discussion of call/answer and
> shoved some REST stuff in there as well.  I posted one version to this
> list but only sent Stef an update since he expressed an interest.  Let
> me see if I can fix it up over the weekend.  I had got bogged down
> trying to add liquid drop shadows and css gradients and (basically)
> broken it ;-)
>
> The basic mechanism is
> 1) #updateUrl: is used by a component to modify the URL
>
> updateUrl: anUrl
>     "Make a RESTful URL.
>     Of the form host:/seaside/home/link/MyLink"
>    
>     anUrl
>         addToPath: 'link';
>         addToPath: link name
>
>
> Just a note here.  I was building a small delicious style bookmark app
> [see pic at end] just for fun.  So my seaside entry point is 'home'
> (for no apparent reason) and then I had REST entry points
> /home/link/Google  /home/tag/Search etc. for taking me straight to a
> view of my links and tags had I navigated there by hand.
>
> 2) a subclass of WARenderLoopMain implementing #start: and possibly
> #createRoot.
>
> (here is some pseudo code for this subclass but I'll send you a
> working example if you want)
>
> start: aRequest
>    
>     | path decision |
>     path := aRequest url findTokens: $/.
>    
>     decision := path interrogateMe.
>     state := InitialState newBasedOn: decision.
>     super start: aRequest
>
> createRoot
>     | root |
>     root := super createRoot.
>     root initialiseWithState: state.
>     ^ root
>
>
> So we grab the url, figure out how we want to set our root component,
> and off we go.  Any further work by #updateUrl: then let's us go back
> around in a circle.  That as far as I knew was pretty much it for REST
> but I'm sure some helpful folks will chime in with what I missed.
>
> On the subject of the GemStone port I figured this would work out of
> the box.
>
> Cheers,
>
> Mike

> 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"  
>> <[hidden email]> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 2) a subclass of WARenderLoopMain implementing #start: and possibly
> #createRoot.
>
> (here is some pseudo code for this subclass but I'll send you a
> working example if you want)
>
> start: aRequest
>
>         | path decision |
>         path := aRequest url findTokens: $/.
>
>         decision := path interrogateMe.
>         state := InitialState newBasedOn: decision.
>         super start: aRequest
>
> createRoot
>         | root |
>         root := super createRoot.
>         root initialiseWithState: state.
>         ^ root

>> 2) a subclass of WARenderLoopMain implementing #start: and possibly
>> #createRoot.
>>
>> (here is some pseudo code for this subclass but I'll send you a
>> working example if you want)
>>
>> start: aRequest
>>
>>         | path decision |
>>         path := aRequest url findTokens: $/.
>>
>>         decision := path interrogateMe.
>>         state := InitialState newBasedOn: decision.
>>         super start: aRequest
>>
>> createRoot
>>         | root |
>>         root := super createRoot.
>>         root initialiseWithState: state.
>>         ^ root
>
> Overriding WAComponent>>#initialRequest: can sometimes avoid the extra
> subclass of WARenderLoopMain. Moreover the code is the closer to the
> counterpart #updateRoot:
>
> Cheers,
> Lukas
>