[Seaside-dev] Sessions should know their keys

[Philippe Marschall]

On Sat, Sep 28, 2013 at 8:34 PM, Julian Fitzell <jfitzell at gmail.com> wrote:
> Yes, I've had the same thought before and I've struggled back and forth with
> it a few times. At some level, I feel like request handlers should be able
> to receive requests via multiple paths (two different server adaptors with
> different encodings, for example), and therefore we should generally be
> relying on a context-based definition of parent (i.e. what's the previous
> handler in the handler's chain), rather than a single container-based
> parent. And that's part of the reason that request handlers don't know their
> keys, I think.

Well yes, currently you can store the same handler under different
keys in the same dispatcher which seems like a strange use case to
optimize for.

> Also, don't we still store instances of other classes in the
> Application?

Yes and no. In theory we still do it but in practice document handlers
are now in sessions.

> I hate that we do that, but if the child knows its key rather
> than the parent, then everything you put in there needs to know a key.
>
> Sessions don't really *need* to know their keys except when generating URLs
> of course (or do they?) and that's a problem common to all request handlers.

Yes, however usually we don't have as many request handlers per
dispatcher as we have sessions per application so #keyForValue: is
less of an issue there. As for sessions specifically I can't think of
a use case where we would like to have two different keys for the same
session.

> As you know, the last change I was playing with was separating the
> "key-based persistence" part of Session from the "application request
> handling" part and one of the things I was struggling with there was how the
> heck do the request handlers know how to refer to themselves. As I said, I
> don't think this problem is unique to sessions, though.
>
> Anyway, just a rambling email that can be summarized with: there are
> certainly good arguments for sessions to know their key; I think there's a
> tension there that still hasn't been perfectly resolved. Maybe it can't be?

We'll I guess it depends to which extent we accept the current
limitations or want to build something more generic.

Cheers
Philippe