Hanno Schlichting wrote:

Laurence Rowe wrote:

...

Quite a lot of zope3 code (zc.datetimewidget for instance) expects to be able to access request.locale. ZPublisher does not provide this and to get around the limitation you must manually set request.locale in your view using Products.CMFDefault.formlib.form.getLocale. This seems brittle. I think it would be desirable to include such functionality in Zope 2. If there is support for this, where should it go? ZPublisher.HTTPRequst or somewhere in Five seem like prime candidates.

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.

+1 Is there maybe a way we can grep the major sources (Zope 2, CMF, Plone, Silva) to look for uses of request.locale and see if this really is a big problem in practice? Or, of course, make the change in a branch and try to look for deprecation warnings. As we're making more of an explicit effort to use Zope 3 components, including UI ones, it seems to me that what Hanno is proposing introduces an acceptable risk and a clear migration for those who were using request.local (just use request['locale'] instead). Martin -- Acquisition is a jealous mistress

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

Dieter Maurer wrote:

Hanno Schlichting wrote at 2007-9-9 11:58 +0200:

...

... Obviously this needs a bit of rather hairy code

Indeed, as you must not define 'locale' as a request attribute (it may hide 'locale' "set otherwise") but otherwise let it behave as if it were an attribute.

We already do something similar for the request.debug variable, but this uses a stack frame hack which limits the debug attribute to be shown to code in the zope.* packages. For the locale this is an undesired limitation as other code (like plone.app.*) would like to use this as well. But we are already overriding each an every access method on the request (like __getattr__, __getitem__, ...) so stuffing some conditional code in there should be possible. I'll try to implement a patch for this. Hanno

Philipp von Weitershausen wrote:

Hanno Schlichting wrote:

...

We already do something similar for the request.debug variable, but this uses a stack frame hack which limits the debug attribute to be shown to code in the zope.* packages.

For the locale this is an undesired limitation as other code (like plone.app.*) would like to use this as well.

I'll try to implement a patch for this.

Thanks. I think you guys are on the right track.

Perhaps we can also sanitize the 'debug' issue at the same time? They should probably be treated equally.

I committed the change to Zope trunk now (r79698). As a nice side-effect I could remove some code in Five's formlib support, which was only working around the issue of the missing request.locale :) As setting up the locale can be a bit slow sometimes (it parses a rather large XML file in the end) I made the loading lazy, so it will only be loaded when accessed first and not on creation of the request. This way requests not needing it should not be slowed down. Hanno