On Wed, Nov 24, 2010 at 2:23 PM, Jacob Kaplan-Moss <[email protected]> wrote: > Ugh, I'm -1 on this. It confuses requests and responses, and abstracts > away a *very* important aspect of how HTTP actually works. Doing this > is semantically unclean and binds together two parts of the > request/response cycle that are separate by design. I don't at all > like the idea of obscuring the truth about how HTTP actually works. > > There's a tiny chance I might be able to be convinced to change my > mind, but you'll have to back up and explain exactly what it is you're > trying to do that's impossible without this hack.
There are just situations where you need to have the ability to cause a cookie to be set, but can't yet create the response object. In my case I was creating a small framework for registering functions that would check for and set messages via the messages framework. If I called the view and passed the request and response to these functions, the messages they'd set wouldn't show until the next response because the page would already have been rendered. If I could stick to only passing in a request then I could put off getting the response object until later, my functions could set cookies, and the messages would show up at the right time. In David Cramer's post on the subject[0] he mentions needing this when building an authentication service. I'm sure there are many other use cases and at least as many hacks that have been put into place to get around this limitation. I'm certainly not married to this implementation. It made sense to me to offer methods with the exact same signature on the request as the response, but I can see you point about confusion. Since they accomplish the same outcome, I don't think any confusion would result in bugs, but it could, so I understand. Would you be more open to a completely separate cookie handling component that the HttResponse.set_cookie and HttResponse.delete_cookie called for backward compatibility? I have no idea how such a thing would work or maintain state through a request-response cycle, but if an alternate new API were created through which one always interacted with cookies, perhaps that would assuage some confusion concerns. I mainly just need to be able to set a cookie from anywhere in a view, or in any decorator or function that deals with the view process. The only way I've found to do that is to use a middleware that monkeypatches the request and then copies whatever was added there to the resopnse on its way out. If there's another way, I'm very happy to hear it. The thing I like most about attempting contributions like this to Django is the learning experience. Thanks for the feedback! Paul [0] http://www.davidcramer.net/code/62/set-cookies-without-a-response-in-django.html -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
