[Seaside] Seaside and REST
nevin at bountifulbaby.com
Wed May 2 17:06:25 UTC 2007
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:
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
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:
Converts back to this once the session expires:
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside