On Jul 2, 11:10 am, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > And have multiple flashes keyed at once.
>
> That seems weird to me... what purpose does the key have? Just so you
> can clear the key with "flash['login_msg'] = None" ?
No, clearing the flash is handled automatically during the next
request, you never clear the flash yourself (by design its around for
the next request only). The purpose of having a keyed one, is so that
multiple functions can easily store a little message without
overriding each other's message. Generally there's only one or two
flashes, and having them keyed makes it easy to avoid overwriting
another one, and store 2 or 3.
> It to me that it should be something like response.flash('message'). I
> think currently there may be some problems with returning WSGI
> applications, and then everything in response is lost; but I think this
> should be fixed generally anyway. Probably with a middleware just
> outside of the HTTPException middleware. Maybe something that looks like:
>
> class PylonsResponseFixup(object):
> def __init__(self, app):
> self.app = app
> def __call__(self, environ, start_response):
> environ['pylons.response_folded_in'] = False
> def repl_start_response(status, headers, exc_info=None):
> if not environ['pylons.response_folded_in']:
> pylons.response.fold_in_headers(headers)
> return start_response(status, headers)
> return self.app(environ, repl_start_response)
>
> class WSGIResponse:
> ...
> def fold_in_headers(self, headers):
> my_headers = self.wsgi_response()[1]
> for name, value in my_headers:
> if name.lower() == 'set-cookie':
> headers.append((name, value))
>
> And when you actually get a WSGIResponse object in the PylonsController,
> just set environ['pylons.response_folded_in'] to True so that the
> middleware doesn't futz with it anymore.
Yea, of course, when you step back and look at this, and some other
crazy things we're doing in the controller right now to handle pulling
vars out, preserving them in the response, etc.... this is all because
one is returning the response object implicitly.
If there was a global response object that you could just set the
headers on, and be done with it, it'd be a lot easier for the
Controller upon returning its output to just use the global response.
I'd highly prefer to go this route, and return to having a global
response object (had one in 0.8), and dump all this additional
complexity one acquires when futzing around with something that should
be easy (setting a cookie regardless of where you are).
So my plan:
1) In 0.9.6, a global response object will be introduced and throw a
future deprecation warning. For all code returning a Response object,
it'll be used with headers from the global one tacked on as
appropriate.
2) In 0.9.7, returning a Response object will raise a deprecation
warning, still no backwards compatibility breakage.
3) In 0.9.8, the global response object will be the only way to set
headers, and other response stuff.
This will simplify a lot of the Controller code that is trying to make
response available in __after__ as such. While small things right now
are deprecated in a version, then removed in the next, this is a
bigger change so it will be deprecated over 2 revisions before
removal.
Cheers,
Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
