Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Chris McDonough
On 05/07/2014 02:26 PM, Jonathan Vanasco wrote: which is why I keep badgering him to weigh in on this issue only. sorry, i feel a bit clearer on what you want to hear now. for this particular need, the others tabled, it's largely testing and troubleshooting -- and it is a bit more advance

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Jonathan Vanasco
On Thursday, May 8, 2014 7:16:43 AM UTC-4, Chris McDonough wrote: > > All of the above use cases presume that you have visibility into the > session implementation's backend to load data. If you do, that's fine, > but there are no APIs in Pyramid that provide this functionality, so > you're a

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Mike Orr
On Thu, May 8, 2014 at 4:16 AM, Chris McDonough wrote: > All of the above use cases presume that you have visibility into the session > implementation's backend to load data. If you do, that's fine, but there > are no APIs in Pyramid that provide this functionality, so you're already in > impleme

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Chris McDonough
On 05/08/2014 01:05 PM, Jonathan Vanasco wrote: Having the ability to uniformly access a session's id across ISession implementations buys you very little in these cases, because you're already relying on implementation details that necessarily go behind the back of ISession. You

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Chris McDonough
On 05/08/2014 01:21 PM, Mike Orr wrote: On Thu, May 8, 2014 at 4:16 AM, Chris McDonough wrote: All of the above use cases presume that you have visibility into the session implementation's backend to load data. If you do, that's fine, but there are no APIs in Pyramid that provide this function

[pylons-discuss] Workaround for forward slashes in URL

2014-05-08 Thread Achim Domma
Hi, I have the following two routes in my application: /{base_id}/{sub_id}/{some_text} /{base_id}/{sub_id} Obviously I assume that none of these parts contains a slash, which has just proven to be wrong. ;-) I have control over some_text, so I can make sure, that it will not contain a slash, b

Re: [pylons-discuss] Workaround for forward slashes in URL

2014-05-08 Thread Gael Pasgrimaud
Hi, On Thu, May 08, 2014 at 01:22:13PM -0700, Achim Domma wrote: > Hi, > > I have the following two routes in my application: > > /{base_id}/{sub_id}/{some_text} > /{base_id}/{sub_id} > > Obviously I assume that none of these parts contains a slash, which has > just proven to be wrong. ;-) I h

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Jonathan Vanasco
On Thursday, May 8, 2014 1:40:58 PM UTC-4, Chris McDonough wrote: > > I'd be surprised. That'd presume the two implementations stored data in > the exact same way, which might well be the case, but can't be assumed. > If it didn't break, it'd only be by happy accident. > agreed. most just

Re: [pylons-discuss] Workaround for forward slashes in URL

2014-05-08 Thread Michael Merickel
Unfortunately you need to double-escape slashes to get them through a wsgi-compliant server. If this isn't an option then in Pyramid you could use a regex in the placeholder of sub_id: {sub_id:some_regex}. If the regex doesn't get you there then you can make use {sub_id:.*} and assign a custom pred

Re: [pylons-discuss] Workaround for forward slashes in URL

2014-05-08 Thread Jonathan Vanasco
I don't think this is doable. if you have this route accept slashes /{base_id}/{sub_id_with_slashes} than how do you differentiate these 2 routes ? /{base_id}/{sub_id_with_slashes} /{base_id}/{sub_id_with_slashes}/{some_text} this url would match both patterns : /base_id/aaa/b

Re: [pylons-discuss] How to store session data server side?

2014-05-08 Thread Chris McDonough
On 05/08/2014 04:42 PM, Jonathan Vanasco wrote: On Thursday, May 8, 2014 1:40:58 PM UTC-4, Chris McDonough wrote: I'd be surprised. That'd presume the two implementations stored data in the exact same way, which might well be the case, but can't be assumed. If it didn't bre