request.locale - do we have this in 2.9.4?
Hi! I'm using Zope 2.9.4 with Five1.4 (linux box). I'm trying to use DateDisplayWidget (from /zope/app/form/browser/textwidgets.py) I get: *Error Type: AttributeError* *Error Value: locale ... Module Products.PageTemplates.Expressions, line 180, in _eval Module Products.PageTemplates.Expressions, line 85, in render Module zope.app.form.browser.textwidgets, line 538, in __call__ Module ZPublisher.HTTPRequest, line 1219, in __getattr__ Which is caused by this line: formatter = self.request.locale.dates.getFormatter( self._category, (self.displayStyle or None)) So is this something with my Zope that I don't have request.locale or is that a bug? -- Maciej Wisniowski *
On 9/5/06, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
I'm using Zope 2.9.4 with Five1.4 (linux box). I'm trying to use DateDisplayWidget (from /zope/app/form/browser/textwidgets.py) [snip] So is this something with my Zope that I don't have request.locale or is that a bug?
I'd say it's a bug. The Zope3 request has the locale attribute, but the Zope2 request implementation doesn't. -- Martijn Pieters
I'd say it's a bug. The Zope3 request has the locale attribute, but the Zope2 request implementation doesn't. Yeah, I supposed that but was not sure. Thanks.
I've submitted an issue: http://www.zope.org/Collectors/Zope/2184 -- Maciej Wisniowski
--On 5. September 2006 15:35:36 +0200 Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
I'd say it's a bug. The Zope3 request has the locale attribute, but the Zope2 request implementation doesn't. Yeah, I supposed that but was not sure. Thanks.
I've submitted an issue:
That's basically a Zope 3 issue and belongs into the Zope 3 bugtracker :-) -aj
--On 5. September 2006 15:49:46 +0200 Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
That's basically a Zope 3 issue and belongs into the Zope 3 bugtracker :-)
Why Zope 3? I'm using Zope 2.9.4. This code is ported directly form Zope 3 or what?
The REQUEST in Zope 2 never had a 'locale' attribute and Zope 2 does not claim to be compatible with every kind of Zope 3 infrastructure. If request.locale is a very important feature in the Zope 3 world, one might backport this somehow to Zope 2 (if it makes sense). I consider this a feature request but not as a bug. -aj
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug is that DateDisplayWidget in Zope2.9.4 uses request.locale which as you said is from Zope3 world. So, as far as I understand, reference to 'request.locale' shouldn't appear in Zope 2.9.4 code at all but it does... Do you mean it is correct?? -- Maciej Wisniowski
--On 5. September 2006 16:24:09 +0200 Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug is that DateDisplayWidget in Zope2.9.4 uses request.locale which as you said is from Zope3 world. So, as far as I understand, reference to 'request.locale' shouldn't appear in Zope 2.9.4 code at all but it does...
Zope 2 does *not* contain a special or modified or adjusted Zope 3 code base. -aj
Maciej Wisniowski wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug
There is no bug.
is that DateDisplayWidget in Zope2.9.4 uses request.locale which as you said is from Zope3 world. So, as far as I understand, reference to 'request.locale' shouldn't appear in Zope 2.9.4 code at all but it does... Do you mean it is correct??
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only pretends to be an IBrowserRequest. At the current state, it can't implement the whole interface. That's a known issue, but we can't do anything about it, at least not in DateDisplayWidget (and numerous other places where request.locale is used). The problem's roots go deeper. Philipp
On 9/5/06, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Maciej Wisniowski wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug
There is no bug.
Sure there is. The Five integration includes code that expects an IBrowserRequest. Either Zope2 should implement that correctly, or Five should not include that widget, or Five should register a widget that doesn't use request.locale. This should be at a minimum be named as a known issue. -- Martijn Pieters
Martijn Pieters wrote:
On 9/5/06, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Maciej Wisniowski wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug
There is no bug.
Sure there is.
It's an issue, not a bug. All things that use DateTimeWidget are simply not supported at this stage.
The Five integration includes code that expects an IBrowserRequest. Either Zope2 should implement that correctly, or Five should not include that widget,
It'd be really really hard not to ship individual components from Zope 3.
or Five should register a widget that doesn't use request.locale.
Patches are welcome :)
This should be at a minimum be named as a known issue.
Sure. I just named it :). Philipp
Philipp von Weitershausen wrote at 2006-9-5 16:44 +0200:
... It's an issue, not a bug.
According to Wikipedia: A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. A request object that declares to implement "IBrowserRequest" but does not, is not working as intended -- and constitutes a bug. -- Dieter
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-5 16:44 +0200:
... It's an issue, not a bug.
According to Wikipedia:
A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result.
A request object that declares to implement "IBrowserRequest" but does not, is not working as intended -- and constitutes a bug.
Fine. Call it a bug. I don't care. Arguing semantics won't solve that problem now, will it. Remove the IBrowserRequest declaration and see Five break. Perhaps it was the wrong thing to do at the time (it certainly wasn't me who did it), but that's just how it is. We'll have to live with it now. Philipp
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only pretends to be an IBrowserRequest. At the current state, it can't implement the whole interface.
That's a known issue, but we can't do anything about it, at least not in DateDisplayWidget (and numerous other places where request.locale is used). The problem's roots go deeper.
I just thought that if there is DateDisplayWidget class in Zope2.9.4 code then it may be used. It is a bit strange for me that Zope contains code that is unuseable. But ok, I'll use something different. -- Maciej Wisniowski
Maciej Wisniowski wrote:
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only pretends to be an IBrowserRequest. At the current state, it can't implement the whole interface.
That's a known issue, but we can't do anything about it, at least not in DateDisplayWidget (and numerous other places where request.locale is used). The problem's roots go deeper.
I just thought that if there is DateDisplayWidget class in Zope2.9.4 code then it may be used. It is a bit strange for me that Zope contains code that is unuseable. But ok, I'll use something different.
It is not unusable if your request correctly implements IBrowserRequest. And even though it is in Zope 2.9.4, it comes from a Zope 3 based library. Five never gave you a guarantee that *all* Zope 3 components would instantly work in Zope 2 as soon as they're shipped with it. Philipp
Philipp von Weitershausen wrote at 2006-9-5 16:28 +0200:
Maciej Wisniowski wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug
There is no bug.
Seems a funny interpretation of "no bug" for me...
is that DateDisplayWidget in Zope2.9.4 uses request.locale which as you said is from Zope3 world. So, as far as I understand, reference to 'request.locale' shouldn't appear in Zope 2.9.4 code at all but it does... Do you mean it is correct??
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only pretends to be an IBrowserRequest.
If that is not a bug (pretending to implement "IBrowserRequest" but not doing so) what is a bug?
At the current state, it can't implement the whole interface.
Which means, that there is a bug but you have currently little chance to fix it... By the way, you could introduce a configuration option that allows the user to determine whether he is more interested in a true "IBrowserRequest" request or a more backward compatible request.
That's a known issue, but we can't do anything about it, at least not in DateDisplayWidget (and numerous other places where request.locale is used). The problem's roots go deeper.
That you know it and do not want to change it does not mean that "bug" is not an appropriate term... -- Dieter
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-5 16:28 +0200:
Maciej Wisniowski wrote:
I consider this a feature request but not as a bug. Ehm... I'm not sure whether we understand each other.
I mean the bug There is no bug.
Seems a funny interpretation of "no bug" for me...
It's an unfortunate situation. That's what it is.
is that DateDisplayWidget in Zope2.9.4 uses request.locale which as you said is from Zope3 world. So, as far as I understand, reference to 'request.locale' shouldn't appear in Zope 2.9.4 code at all but it does... Do you mean it is correct?? DateDisplayWidget expects an IBrowserRequest. Zope 2's request only pretends to be an IBrowserRequest.
If that is not a bug (pretending to implement "IBrowserRequest" but not doing so) what is a bug?
I'll call this an "issue" for now, but I won't argue semantics here. All I can say is that the Five project's promises were never that everything from Zope 3 works instantly. And it has also been Five's policy to make a quick lie here and there just to get things going. Five usually gives you 95% of a certain technology you know from Zope 3. The remaining 5% are friction loss due to Zope 2isms like Acquisition, etc. In order to "sell" Zope 2's request to the Zope 3 machinery, Five originally made Zope 2's request an IBrowserRequest -- even though that was a lie. When Five was integrated into Zope 2, that lie was carried on in Zope 2. I was neither the one to make that initial "lie" nor was I there when Five was integrated.
At the current state, it can't implement the whole interface.
Which means, that there is a bug but you have currently little chance to fix it...
The problem with going forward with this and fixing it is the following (quoting myself from an earlier email on this thread): We can't even just make the Zope 2 request have that attribute because of potential backward incompatibilities. Why? Because you can do request.locale in Zope 2 right now which is an equivalent spelling of request['locale'] (it looks up request variables). If existing applications use the attribute access instead of the item access (which should clearly be the preferred way, but there's lots of Zope 2 legacy), they would break because request.locale would now find something else. It's not a bug. It's Zope 2's obscenity with __getattr__ APIs instead of __getitem__ APIs that's preventing the harmonizing of the two implementations, that's all. Both the ObjectManager and the request are very good examples of how Zope 2 got this wrong, but Zope 3 got it right.
By the way, you could introduce a configuration option that allows the user to determine whether he is more interested in a true "IBrowserRequest" request or a more backward compatible request.
I'm not sure that that will work. In complicated systems like Plone, you might end up with some products that rely on the old way of doing things while Plone uses Zope 3 components that obviously want the "true" IBrowserRequest request at same time. Note that I'm well aware of this issue and have thought hard about it. I think the only long term solution out of this mess is to get rid of the __getattr__ spelling once and for all.
That's a known issue, but we can't do anything about it, at least not in DateDisplayWidget (and numerous other places where request.locale is used). The problem's roots go deeper.
That you know it and do not want to change it does not mean that "bug" is not an appropriate term...
You're claiming that I don't *want* to change it. That's not true. I am thinking hard about this, but I see no easy solution. Of course, I'd be more than happy if an easy solution can be found. Philipp
I'll call this an "issue" for now, but I won't argue semantics here. All I can say is that the Five project's promises were never that everything from Zope 3 works instantly. And it has also been Five's policy to make a quick lie here and there just to get things going. Five usually gives you 95% of a certain technology you know from Zope 3. The remaining 5% are friction loss due to Zope 2isms like Acquisition, etc.
I don't catch one thing. There is Five/formlib/formbase.py where Five overrides handle_edit_action. Why it is overriden? "To remove dependecy on request.locale". Why can't be same thing done with DateDisplayWidget? Isn't this a simple solution? -- Maciej Wisniowski
Maciej Wisniowski wrote:
I'll call this an "issue" for now, but I won't argue semantics here. All I can say is that the Five project's promises were never that everything from Zope 3 works instantly. And it has also been Five's policy to make a quick lie here and there just to get things going. Five usually gives you 95% of a certain technology you know from Zope 3. The remaining 5% are friction loss due to Zope 2isms like Acquisition, etc.
I don't catch one thing. There is Five/formlib/formbase.py where Five overrides handle_edit_action. Why it is overriden? "To remove dependecy on request.locale".
Why can't be same thing done with DateDisplayWidget? Isn't this a simple solution?
Sure. As I said earlier, we are happy to accept patches :) Philipp
Sure. As I said earlier, we are happy to accept patches :)
I've written simple path that, at last, causes DateDisplayWidget doesn't raise exceptions and has minimalistic locale aware date formatting (according to docs about time module and strftime function with %x and %X). I've added overrides.zcml that redefines DateDisplayWidget and DatetimeDisplayWidget. File textwidgets.py should be placed in Five/form/ and overrides.zcml in Five/ (possibly there should be rather include of Five/form/overrides.zcml) I'm not sure if it is suitable to Five philosophy (especially overrides) so comments are welcome. Another idea of being locale aware with DateDisplay widgets is similiar to one used in CalZope from Nuxeo.Use translation to get proper (locale aware) date formats. But I'm not sure where such translations should be defined and what are 'short', 'medium', 'long' and 'full' formats used by getFormatter in Zope3. I mean something like: msgid = _('YYYY-MM-DD') res = translate(msgid, context=self.request, default=msgid) return renderElement("span", contents=escape(res), cssClass=self.cssClass) -- Maciej Wisniowski <configure xmlns="http://namespaces.zope.org/zope" xmlns:browser="http://namespaces.zope.org/browser"> <view type="zope.publisher.interfaces.browser.IBrowserRequest" for="zope.schema.interfaces.IDate" provides="zope.app.form.interfaces.IDisplayWidget" factory=".form.textwidgets.DateDisplayWidget" permission="zope.Public" /> <view type="zope.publisher.interfaces.browser.IBrowserRequest" for="zope.schema.interfaces.IDatetime" provides="zope.app.form.interfaces.IDisplayWidget" factory=".form.textwidgets.DatetimeDisplayWidget" permission="zope.Public" /> </configure>
msgid = _('YYYY-MM-DD') res = translate(msgid, context=self.request, default=msgid) return renderElement("span", contents=escape(res), cssClass=self.cssClass)
Eh.. some lines disappeared ;) from the above code. Should be something like: from zope.i18nmessageid import MessageFactory _ = MessageFactory("calendar") msgid = _('%Y-%m-%d') format = translate(msgid, context=self.request, default=msgid) content = content.strftime(format) return renderElement("span", contents=escape(content), cssClass=self.cssClass) -- Maciej Wisniowski
Philipp von Weitershausen wrote at 2006-9-5 20:57 +0200:
... Note that I'm well aware of this issue and have thought hard about it. I think the only long term solution out of this mess is to get rid of the __getattr__ spelling once and for all.
The "__getattr__" may be a stumbling block in principle. Practically, it will very rarely hinder you to add attributes (such as "locale") to the request. True: you can use "REQUEST.locale" or "REQUEST.debug" and expect to access in fact "REQUEST['locale'] and "REQUEST['debug']" respectively. But, it is rare that the attribute access syntax is used and if it indeed results in the wrong result (because the request grew additional attributes), then it is easy to fix. Adding the configuration option would (perhaps) make the administrator aware of the potential cause when he gets informed about wrong values read from the request. -- Dieter
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-5 20:57 +0200:
... Note that I'm well aware of this issue and have thought hard about it. I think the only long term solution out of this mess is to get rid of the __getattr__ spelling once and for all.
The "__getattr__" may be a stumbling block in principle.
Practically, it will very rarely hinder you to add attributes (such as "locale") to the request.
I think "locale" and "debug" are just common enough to be form variables.
True: you can use "REQUEST.locale" or "REQUEST.debug" and expect to access in fact "REQUEST['locale'] and "REQUEST['debug']" respectively.
But, it is rare that the attribute access syntax is used
You'd be surprised (I was too). Plus, TALES path expressions first try attribute access, then item access.
and if it indeed results in the wrong result (because the request grew additional attributes), then it is easy to fix.
Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I wouldn't mind. But I'm sure others would.
Adding the configuration option would (perhaps) make the administrator aware of the potential cause when he gets informed about wrong values read from the request.
Perhaps. A configuration option (that would usually be turned to 'off') would surely be a quick way of finding out where you have code that uses request.foo. It may be a good step leading an actual deprecation of the __getattr__ spelling (which I think is necessary for eliminating the reuquest.foo spelling once and for all, especially in newly created code). Philipp
Philipp von Weitershausen wrote:
Practically, it will very rarely hinder you to add attributes (such as "locale") to the request.
I think "locale" and "debug" are just common enough to be form variables.
Funny, I've never used either in 6 years of zoping ;-)
You'd be surprised (I was too). Plus, TALES path expressions first try attribute access, then item access.
ZPT sux ;-)
Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I wouldn't mind. But I'm sure others would.
I thought adapters were for this exact kind of thing? Existing Zoep 2 code would use a Zope 2 request, the Zope 3 components should be presented with a Zope 2 request that has been adapted to present IBrowserRequest rather than just being marked as implementing it, no?
Perhaps. A configuration option (that would usually be turned to 'off')
What do you mean by "off" here? The config option should make the stfuf that ships (like the widgets!) work by default... cheers, Chrus -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
Practically, it will very rarely hinder you to add attributes (such as "locale") to the request.
I think "locale" and "debug" are just common enough to be form variables.
Funny, I've never used either in 6 years of zoping ;-)
Me neither, but are we prepared to break the apps of the people who do? (Btw, just thought of another one possible name clash: 'response')
You'd be surprised (I was too). Plus, TALES path expressions first try attribute access, then item access.
ZPT sux ;-)
TALES path expression sux (for various reasons).
Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I wouldn't mind. But I'm sure others would.
I thought adapters were for this exact kind of thing? Existing Zoep 2 code would use a Zope 2 request, the Zope 3 components should be presented with a Zope 2 request that has been adapted to present IBrowserRequest rather than just being marked as implementing it, no?
This would have been a possible solution at the time, but it wasn't chosen. Neither the people who introduced IBrowserRequest to Zope 2 nor I who pretty much took on Five maintenance afterwards realized this problem back then. I've thought about introducing the adaption approach now. I think we'd be opening a can of worms since the request objects are likely to be passed from old style code to new style code and vice versa.
Perhaps. A configuration option (that would usually be turned to 'off')
What do you mean by "off" here? The config option should make the stfuf that ships (like the widgets!) work by default...
I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 doesn't mean that everything from the 'zope' namespace has to work. Five has never made that promise. That said, *if* we choose to go with such a configuration option, I think it woudl probably be a good idea to have it disabled by default in the first release and enabled in subsequent releases. That way applications could opt in for the new behaviour earlier than necessary (much like Python's __future__ imports). Philipp
On Wed, 2006-06-09 at 13:52 +0200, Philipp von Weitershausen wrote:
That said, *if* we choose to go with such a configuration option, I think it woudl probably be a good idea to have it disabled by default in the first release and enabled in subsequent releases. That way applications could opt in for the new behaviour earlier than necessary (much like Python's __future__ imports).
My 2 cents here. I've also spent a great deal of time pondering this particular problem. And there has been some good discussion in this thread. Personally what I'm leaning towards liking the most would be an approach that blends the configuration and adapter ideas discussed here. Five version X would introduce an IBrowserRequest adapter for a zope 2 request and a new zcml directive, say five:zope3request, that would toggle whether or not Five should pass through the adapted request instead of the raw request. By default it would not adapt (for BBB compat). We could consider issuing a deprecation message saying the default will be changed with future Five release. And with Five version X+1 or X+2 we change the default to adapt. I'd propose version X would be 1.5 and the release that sets the default to zope3 requests be version 1.6. We could always keep around the five:zope3request directive even after we change the default so that people who really need old-style behaviour (raw zopee 2 requests) can still re-activate it. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
Philipp von Weitershausen wrote:
Funny, I've never used either in 6 years of zoping ;-)
Me neither, but are we prepared to break the apps of the people who do?
I'd assert that no-one does...
(Btw, just thought of another one possible name clash: 'response')
no-one uses that is Zope 2 land 'cos of RESPONSE...
I've thought about introducing the adaption approach now. I think we'd be opening a can of worms since the request objects are likely to be passed from old style code to new style code and vice versa.
I think it's worth at least trying...
I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 doesn't mean that everything from the 'zope' namespace has to work. Five has never made that promise.
Indeed, but in this circumstance, they probably should ;-)
That said, *if* we choose to go with such a configuration option, I think it woudl probably be a good idea to have it disabled by default in the first release and enabled in subsequent releases. That way applications could opt in for the new behaviour earlier than necessary (much like Python's __future__ imports).
OK, I'll buy that, annoying though it'll be for everyone (no-one has spoken up to say "you're gonna break all my code is you use debug, or locale, or response" ;-) ) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
(Btw, just thought of another one possible name clash: 'response')
no-one uses that is Zope 2 land 'cos of RESPONSE...
Well. Could be that someone uses 'response' as a form variable, as in "the response to a question" in a QandA system, perhaps. The sad thing about this is that we can only do so much investigation of existing code. The rest is speculation. But it's better to be safe than sorry...
I've thought about introducing the adaption approach now. I think we'd be opening a can of worms since the request objects are likely to be passed from old style code to new style code and vice versa.
I think it's worth at least trying...
Agreed. This thing has always been on my agenda, but it needs thought and time to do it.
I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 doesn't mean that everything from the 'zope' namespace has to work. Five has never made that promise.
Indeed, but in this circumstance, they probably should ;-)
Agreed.
That said, *if* we choose to go with such a configuration option, I think it woudl probably be a good idea to have it disabled by default in the first release and enabled in subsequent releases. That way applications could opt in for the new behaviour earlier than necessary (much like Python's __future__ imports).
OK, I'll buy that, annoying though it'll be for everyone (no-one has spoken up to say "you're gonna break all my code is you use debug, or locale, or response" ;-) )
True. Hey, don't get me wrong. I'm all *for* going forward and make Zope 2's request more like IBrowserRequest. But in the end when I break other people's apps, everyone will be all over me. I'm sure if it was one of your apps, you'd be the first one to complain and declare Zope's rate of change too fast and harmful. ;) Philipp
Philipp von Weitershausen wrote at 2006-9-7 15:08 +0200:
Chris Withers wrote:
(Btw, just thought of another one possible name clash: 'response')
no-one uses that is Zope 2 land 'cos of RESPONSE...
Well. Could be that someone uses 'response' as a form variable, as in "the response to a question" in a QandA system, perhaps.
Then, he will loose already now: "response" *IS* an attribute of "ZPublisher.HTTPRequest.HTTPRequest". It contains the "response" object passed in when the request object was created. -- Dieter
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-7 15:08 +0200:
Chris Withers wrote:
(Btw, just thought of another one possible name clash: 'response') no-one uses that is Zope 2 land 'cos of RESPONSE... Well. Could be that someone uses 'response' as a form variable, as in "the response to a question" in a QandA system, perhaps.
Then, he will loose already now:
"response" *IS* an attribute of "ZPublisher.HTTPRequest.HTTPRequest". It contains the "response" object passed in when the request object was created.
Ah, didn't look closely enough. Thanks. Even better.
Martijn Pieters wrote:
On 9/5/06, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
I'm using Zope 2.9.4 with Five1.4 (linux box). I'm trying to use DateDisplayWidget (from /zope/app/form/browser/textwidgets.py) [snip] So is this something with my Zope that I don't have request.locale or is that a bug?
I'd say it's a bug.
No it's not.
The Zope3 request has the locale attribute, but the Zope2 request implementation doesn't.
Right. Who ever said that the Zope 2 request is compatible with the Zope 3 request? We can't even just make the Zope 2 request have that attribute because of potential backward incompatibilities. Why? Because you can do request.locale in Zope 2 right now which is an equivalent spelling of request['locale'] (it looks up request variables). If existing applications use the attribute access instead of the item access (which should clearly be the preferred way, but there's lots of Zope 2 legacy), they would break because request.locale would now find something else. It's not a bug. It's Zope 2's obscenity with __getattr__ APIs instead of __getitem__ APIs that's preventing the harmonizing of the two implementations, that's all. Both the ObjectManager and the request are very good examples of how Zope 2 got this wrong, but Zope 3 got it right. Philipp
participants (7)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Maciej Wisniowski -
Martijn Pieters -
Philipp von Weitershausen -
Rocky Burt