[Seaside-dev] Sessions should know their keys

[Julian Fitzell]

On Sun, Sep 29, 2013 at 2:47 PM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:

> On Sat, Sep 28, 2013 at 8:34 PM, Julian Fitzell <jfitzell at gmail.com>
> wrote:
>  > 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.
>

No, nor can I. I also don't think Applications should be holding onto any
handlers other than Sessions in the session dictionary. So maybe it does
make sense to optimize there. Maybe Application should just subclass
RequestHandler directly.

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


I guess I'm always uncomfortable solving a problem in one place when I can
see a more general form exists in other places. There's definitely
something "not quite right" about how we hold handler keys and how we
generate URLs. But Applications holding onto Sessions is definitely a
special case and I don't think there's anything wrong with them being more
tightly coupled since they always work together.

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20130930/299795a0/attachment.htm