[Seaside] 'Clean' URLs in Seaside

Phil (list) pbpublist at gmail.com
Thu May 7 18:34:07 UTC 2015


On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
> On Mon, May 4, 2015 at 11:27 AM, Phil (list) <pbpublist at gmail.com> wrote:
> > I managed to get Seaside 2.x to use 'clean' URLs by following Ramon's
> > post here http://onsmalltalk.com/clean-urls-in-seaside/  a while back.
> > However, some things appear to have changed in 3.x and what needs to
> > change to get rid of the _k parameter (i.e. move it into a cookie) is
> > different now.  So could anyone with experience in doing this in 3.x
> > share what's involved?
> >
> > Also, it's understandable why passing this in the URL was the way to go
> > 5+ years ago, but cookies are pretty widely accepted as requirements on
> > many sites these days.
> Some countries also have cookie laws (yes, really) that don't apply
> when you don't use cookies.

Good point... I'm so used to seeing those 'this site uses cookies'
warnings that I assumed the majority of EU (and other countries with
similar laws) sites just addressed it via disclosure.  That is a very
good reason not to enable cookies by default.

> > Is there some reason this hasn't been made a
> > simple config option as it was for the _s parameter?  Seems like it
> > would be pretty popular...
> _k is used to identify the state snapshot. When you hit the back
> button you need to get the old _k so that Seaside can revert the
> component state. That's why it is technically not possible to
> implement it with a cookie. Are you willing to give up state
> snapshoting?

Thanks for explaining this... I hadn't thought it through but now
understand why what I was asking for wouldn't work.  To answer your
question: yes, I would be willing to give up the state snapshot to get
rid of the parameter.  For this application (basically a simple database
lookup app), it looks like I can pass all the state needed via
#updateUrl: to get a bookmark-friendly URL so I think just dropping _k
entirely could work for me.  How would I do that?

In the end, the best way I can think to describe what I'm trying to get
to is essentially an app that is 'RESTful enough' but still using the
Seaside component model to build its pages.  I understand that I'd be
giving up the page to page state on the server side for anything that is
not manually passed. (i.e. the app may have 'foo', 'bar' and 'baz' state
variables but if it's only passed 1 or 2 of the 3 as parameters, use
defaults for whatever is missing and carry on)

> Cheers
> Philippe
> _______________________________________________


More information about the seaside mailing list