[Seaside] Seaside and REST

[Nevin Pratt]

This Seaside API looks like it can be a functional replacement to my 
hack that I mentioned in my post.

That is very good.  I can eliminate my hack as I move to the newer Seaside.

Nevin

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