cookies

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/2/19, Ramon Leon <[hidden email]>:
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.

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

(Damn more refactorings ahead)

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside