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.
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only
pretends to be an IBrowserRequest.
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??
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 - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -