'Clean' URLs in Seaside

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

'Clean' URLs in Seaside

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

Thanks,
Phil

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Esteban A. Maringolo
The shortcoming of using _s in a cookie is that you cannot open a
separate tab and start a new session. The session is "per browser"
(UA). Which is commonplace behavior these days, but I don't think it
will add much just moving the parameter from one place to another.

You can have bookmarkable URLs in your app though, but even when
Seaside supports that (via the #updateUrl: method), there is no
framework to automatically generate RESTful URIs and route back the
requests composing the component tree according to requested URL.

Regards,

Esteban A. Maringolo


2015-05-07 9:33 GMT-03:00 Philippe Marschall <[hidden email]>:

> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Phil B
In reply to this post by Philippe Marschall
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?

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

Thanks,
Phil


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Phil B
In reply to this post by Esteban A. Maringolo
Esteban,


On Thu, 2015-05-07 at 09:55 -0300, Esteban A. Maringolo wrote:
> The shortcoming of using _s in a cookie is that you cannot open a
> separate tab and start a new session. The session is "per browser"
> (UA). Which is commonplace behavior these days, but I don't think it
> will add much just moving the parameter from one place to another.
>

That's an excellent point and I'll keep it in mind.  For my current app,
I don't need to know much about a session other than as a way to tell
that one request is from a different person than another.  Even then,
it's fairly generic and anonymous (i.e. think user preferences rather
than shopping carts)

> You can have bookmarkable URLs in your app though, but even when
> Seaside supports that (via the #updateUrl: method), there is no
> framework to automatically generate RESTful URIs and route back the
> requests composing the component tree according to requested URL.
>

True, you give up automatic URL handling.  But for some apps, that's a
worthwhile trade-off without going the full RESTful route (at least as
described in the Seaside book)

> Regards,
>
> Esteban A. Maringolo

Thanks,
Phil

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Philippe Marschall
In reply to this post by Phil B
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

Having said all of that maybe it is easier to avoid sessions in your
case and use Seaside-REST and do your own rendering with:

WAHtmlCanvas builder
        fullDocument: true;
        render: MyPainter  new

Just remember you can't do #callback: in this case either.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: 'Clean' URLs in Seaside

Phil B
On Tue, 2015-05-12 at 08:07 +0200, Philippe Marschall wrote:

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

Fantastic... that definitely helps get me going in the right direction.

> Having said all of that maybe it is easier to avoid sessions in your
> case and use Seaside-REST and do your own rendering with:
>
> WAHtmlCanvas builder
>         fullDocument: true;
>         render: MyPainter  new
>
> Just remember you can't do #callback: in this case either.
>

I've looked at this but it appears to be overkill for my needs, and much
more work in the long term from a maintenance standpoint.  Going through
this exercise is giving me a good understanding of why this is
non-trivial in terms of providing a generic solution for a middle
path...

> Cheers
> Philippe

Thanks,
Phil

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