[Seaside] Seaside and REST
nevin at bountifulbaby.com
Thu May 3 00:03:14 UTC 2007
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.
> 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"
> 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
> (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
> | 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.
More information about the Seaside