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

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? -- Maciej Wisniowski

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

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

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

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

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

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

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

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

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

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

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

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

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