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

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.

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

Reply via email to