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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |