On Wed, Nov 24, 2010 at 1:50 PM, Paul McLanahan <[email protected]> wrote:
> 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.
Okay, but you've said this twice without giving any examples. Which
makes it very easy for me to argue that in fact any trying to set a
cookie without a response object around is just a badly-designed or
-factored application. I believe that argument, so you're going to
need to show concrete examples.
> 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.
I'm really not following this "next response because the page has
already been rendered" thing -- if you create the reponse object, pass
it into your utility functions, then return it that creates the
cookies just fine.
> 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.
David's post uses this example::
def my_view(request):
request.COOKIES.set([args])
...
return response
How in any way is that better than::
def my_view(request):
response = HttpResponse(...)
response.COOKIES.set(...)
...
return response
Okay, it saves one line of code, but in the Python world you don't get
bonus points for shorter more obscure code.
> 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.
Again, *why*? Cookies are just an HTTP response header. What purpose
does hiding HTTP's semantics serve?
> 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.
* Views::
def my_view(request):
response = HttpResponse(...)
...
response.write(...)
...
response.COOKIES.set(...)
...
return response
* Decorators::
def my_decorator(viewfunc):
def _inner(request, *args, **kwargs):
response = viewfunc(request, *args, **kwargs)
response.COOKIES.set(...)
return response
return _inner
* Arbitrary functions::
def some_function(response):
response.COOKIES.set(...)
...
It's possible I'm missing something, but I really can't see that some
sort of magic global cookie handling adds enough utility to outweigh
its unintuitiveness.
Of course, you're certainly free to implement some magic middleware
thing in your own code -- it's easy enough to hang something off the
request object then transfer it to the response on the way out. It
certainly wouldn't pass a code review if *I* was performing it, but
luckily your app doesn't have to live up to my standards :)
Jacob
--
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.
