[Seaside] Clean URLs in Seaside

[Philippe Marschall]

2011/9/19 David Buck <david at simberon.com>:
> What's the status of clean URLs in Seaside? I've read Ramon Leon's article
> on Clean URLs in Seaside but the approach doesn't seem to apply to Seaside
> 3.0. I've loaded Seaside-REST and although I like the pragmas to describe
> the URL pattern, I'm left with a method where I need to hand-code HTML
> inside a WARequestHandler subclass without being able to use the rest of the
> Seaside framework that assumes that we have sessions and HTML Canvases.

Untrue, you can use the canvas and presenters. Having that said
Seaside-REST more targeted at RESTful webservices.

> I've
> tried Dale Henrick's heretical approach ("Making ‘_k’ and ‘_s’ optional: A
> Seaside Heresy?") but that doesn't work in Seaside 3.0.
>
> Ideally, I would like the following.
>
> My web application can work in "Window shopping mode" or "Logged in mode".
>
> When window shopping, no state information is needed and the web site is
> navigable without _s or _k parameters either in the URLs or in cookies. All
> pages are bookmarkable and search engine indexable allowing anyone with the
> URL to navigate to the page.
>
> In Logged In Mode, additional options become available in the web pages.
> Users can now do things like add to their carts, sort pages by various
> criteria, add comments, etc. In this mode, the URLs start with the same
> string as in window shopping mode but afterward, _s or _k parameters may be
> added (or _s stored in cookies). I want the same web components with the
> same code to handle both logged in and window shopping modes with tests
> like:
>
> self isLoggedIn ifTrue: [
> self renderShoppingCartOn: html].
>
> Is this possible?

If you are very, very careful and know exactly what you do you can do
this. When #isLoggedIn answers false you must no use #callback: (and
#call: and friends) or #document: and some other things.

A rough outline of what you have to do:
 - add a filter (can be WARestfulFilter) to your application
 - if there's a session (either field or cookie) you just forward
 - #isLoggedIn can just look in the request context if there's a session
 - otherwise you have to come up with a root component, initialize
it's state from the request (you can use Seaside-REST but don't have
to) and then render it
 - you'll have to write some special code for the login that registers
the session in the application and adds it to the response (either a
redirect or a cookie)

> Is there a standard way to do this? I'd like to use
> Seaside-REST but with just a WAHandler I have no easy way to render standard
> Seaside web pages that assume that you have a session and subclass from
> WAComponent.

Yes, sessions (state) and REST don't mix. Components assume state.
That's why mixing them is tricky.

Cheers
Philippe