Clean URLs in Seaside

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

David Buck



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2011/9/19 David Buck <[hidden email]>:
> 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.

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside