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.

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to