[Seaside] Seaside and REST

[Michael Roberts]

On 2 May 2007, at 18:06, Nevin Pratt wrote:


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

 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rest.jpg
Type: image/jpeg
Size: 34209 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070502/6495ef41/rest-0001.jpg
-------------- next part --------------