[Seaside-dev] session tracking refactoring: all tests green

[Philippe Marschall]

2011/7/19 Philippe Marschall <philippe.marschall at gmail.com>:
> 2011/7/19 Julian Fitzell <jfitzell at gmail.com>:
>> On Mon, Jul 18, 2011 at 1:40 PM, Philippe Marschall
>> <philippe.marschall at gmail.com> wrote:
>>> 2011/7/18 Julian Fitzell <jfitzell at gmail.com>:
>>>> On Sun, Jul 17, 2011 at 1:47 PM, Philippe Marschall
>>>> <philippe.marschall at gmail.com> wrote:
>>>>> Hi
>>>>>
>>>>> I'm happy to report that the session tracking refactoring in the WIP
>>>>> repository [1] is mostly done. Have a look at
>>>>
>>>> I'll take a look.
>>>>
>>>>> WAHandlerTrackingStrategy to get started. The missing things are:
>>>>>  - more tests
>>>>>  - class comments
>>>>>  - WARegistryKeyHandlingTest and WAApplicationKeyHandlingTest need to
>>>>> be refactored, there are some nonsensical tests there like two
>>>>> sessions, one identified by a query field and one by a cookie
>>>>
>>>> Why is that a nonsensical test? It happens any time someone clicks on
>>>> a link/bookmark and also has a cookie from a previous session hanging
>>>> around...
>>>
>>> If the user agent accepts cookies the session key will not show up in
>>> the URL. Only the very first link he clicks linking to an action page
>>> will have it but the following render page won't. So it won't show up
>>> the address bar. Also we probably do the wrong thing. We should
>>> probably take the session from the cookie. However we currently give
>>> preference to the query field because document handlers are tracked
>>> using query fields.
>>
>> Our logic, which I still think is sound, is that *if* you pass in a
>> session key on the URL you are asking to override what is in the
>> cookie. I agree that in common usage that's not going to come up very
>> often, but in cases where both are present in a request I still think
>> priority should be given to the query field; the user has requested a
>> specific resource at a specific URL that includes a session key, it
>> seems weird to ignore that key if the session actually exists (and
>> note that if it doesn't, we should actually maybe return a redirect
>> response to a URL without the session key, which could then be handled
>> using the cookie).
>
> The test is still there. I just moved it from registry tests to
> application tests because only sessions session support cookies and

only applications support sessions.

Cheers
Philippe