Dieter Maurer wrote:
Hanno Schlichting wrote at 2007-9-8 00:47 +0200:
... My suggestion on this would be to make request.locale available in Zope 2.11. It would not be available through any of the other means like request['locale'] or request.form['locale'] but just as a simple property on the request itself.
You would still be able to override it, but the set method for it would emit a deprecation warning telling you that you should not use this specific name anymore.
The only backward incompatible change this would introduce from what I can tell is that checking for the presence of request.locale would suddenly give you a true value whereas it would have raised an error before. Given the unlikelihood of this and the major benefit of being able to use more unchanged Zope3 code, I personally would find this acceptable.
The backward incompatibility is a bit bigger:
It arises when "locale" is used as a form variable or as a cookie (or used in "Request.set").
Old code can assume that "request.XXXX" and "request['XXXX']" usually returns the same value, at least for 'locale'.
This changes when you add "locale" as an attribute.
I didn't make myself clear it seems. What I meant by the special set method is that as soon as you set anything that would have changed the value of locale (be it directly, form or cookie) you still change all of them but get the deprecation warning. This ensures that whenever you wrote the value ones, you still get the old behavior. The only change this introduces is that testing explicitly for request.locale before you changed the value will get you a different result. Testing request['locale'] or request.form['locale'] won't change, though. Obviously this needs a bit of rather hairy code, but it's the best compromise I can think of. Hanno