[Seaside] Re: [Seaside-dev] cookies
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?
> 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
(Damn more refactorings ahead)
More information about the seaside