[Seaside] Re: [Seaside-dev] cookies

[Philippe Marschall]

2008/2/19, Ramon Leon <ramon.leon at allresnet.com>:
> > Hi
> >
> > I'm currently reviewing our cookie support. One of the things
> > I noted is that whereas cookies in WAResponse is a Set of
> > WACookie in the WARequest is a Dictionary mapping String to
> > String. This allows for easy programming like:
> >
> > aReqest cookies keysAndValuesDo: [ :key :value |
> >      ....
> >
> > but is quite inconsistent. Any opinions on this? How often
> > are cookies read from the request?
> >
> > Cheers
> > Philippe
>
> Not that I use them much, but I'd say it should be cookie objects on both
> ends, and while you're looking at it can you explain why setting a cookie
> requires a redirect?

It's rather tricky to access the "current response". We need to have
proper contexts and scopes (yes, JEE) else this is never going to fly.

> What if I want to set several cookies?  What if I want
> to drop cookies like breadcrumbs for later use, why should I have to suffer
> a redirect now?
>
> Good example, though I don't use cookies in Seaside, to easily hand off
> booking requests to our .Net app, I could drop a few cookies and just link
> off, but because of how Seaside handles cookies, I took a different
> approach.  Setting cookies should act like a queue, they build up and become
> effective on the next natural refresh.  Forcing every cookie to become
> immediately valid with an immediate redirect seems rather draconian.

Yeah, kinda depends on your definition of "next natural refresh" but
basically, yeah.

(Damn more refactorings ahead)

Cheers
Philippe