[Seaside] Re: [Seaside-dev] cookies

Philippe Marschall philippe.marschall at gmail.com
Tue Feb 19 17:36:00 UTC 2008

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)


More information about the seaside mailing list