Ben Bangert wrote:
> 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.
OK, then that's just weird ;) If it's a function/method like
flash(message) then you just append that to a list of flashed messages,
and it works. A meaningless key is just distracting.
> 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.
While you are reworking some of this response stuff, maybe a cleaner way
to forward the request to a WSGI application could be added. Like
"return self.forward(wsgi_app)", meaning "return
wsgi_app(request.environ, self.start_response)".
Another technique for doing all this stuff would be to just have a
somewhat fancier way to turn the return value into a full WSGI response.
Something like:
class WSGIController: ...
def __call__(self, environ, start_response):
glob_response = Response()
pylons.response._push_object(glob_response)
headers_merged = []
start_response_called = []
def repl_start_response(status, headers, exc_info=None):
if not headers_merged:
glob_response.merge_headers(headers)
start_response_called.append(None)
return start_response(status, headers, exc_info)
self.start_response = repl_start_response
# current __before__, _dispatch_call, __after__ code
if response is glob_response:
# We don't need to merge the headers again
headers_merged.append(None)
if not start_response_called:
if hasattr(response, 'wsgi_response'):
status, headers, app_iter = response.wsgi_response()
else:
status, headers, app_iter = glob_response.wsgi_response()
repl_start_response(status, headers)
response = app_iter
elif hasattr(response, 'wsgi_response'):
# forget about status/headers
response = response.wsgi_response()[2]
# Handle unicode, etc, here:
app_iter = filter_app_iter(response)
return app_iter
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
| Write code, do good | http://topp.openplans.org/careers
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
