'Clean' URLs in Seaside

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

> On Mon, May 4, 2015 at 11:27 AM, Phil (list) <[hidden email]> 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.
>
>> 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?
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> On Mon, May 4, 2015 at 11:27 AM, Phil (list) <[hidden email]> 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.

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

> Philippe,
>
> On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
>> On Mon, May 4, 2015 at 11:27 AM, Phil (list) <[hidden email]> 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?

> On Thu, May 7, 2015 at 8:34 PM, Phil (list) <[hidden email]> wrote:
> > Philippe,
> >
> > On Thu, 2015-05-07 at 14:33 +0200, Philippe Marschall wrote:
> >> On Mon, May 4, 2015 at 11:27 AM, Phil (list) <[hidden email]> 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?
>
> There is a way of doing this if you never use #callback: and a more
> complicated one if you want to use #callback:. Time to learn some
> Seaside :-)
>
> 1. You need a custom WAActionPhaseContinuation subclass that doesn't
> make a state snapshot in #continue, maybe you can just get way with
> implementing #captureState empty
> 2. You need a custom WARenderPhaseContinuation subclass that
> implements #processRendering: so that the continuation is not added to
> the action URL.
> 3. You need a custom WASession subclass that knows your two
> continuations and implements #handleFiltered: so that it finds them
> without _k. Is is a bit trickier to do if you do a redirect after
> action processing. If you don't do a redirect reloading the page will
> execute the last callback again.
> 4. if you want to use #callback: you have to implement a custom
> WACallbackRegistry that "forgets" old callbacks
>