On 8/20/06, Alec Mitchell [EMAIL PROTECTED] wrote:
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote:
...
In our local Zope version, I implemented a solution that is
(in my opinion) superior:
Define an exception UseTraversalDefault that can be
used by __bobo_traverse__ to tell the
On 8/21/06, Lennart Regebro [EMAIL PROTECTED] wrote:
On 8/20/06, Alec Mitchell [EMAIL PROTECTED] wrote:
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote:
...
In our local Zope version, I implemented a solution that is
(in my opinion) superior:
Define an exception UseTraversalDefault
On 8/21/06, Alec Mitchell [EMAIL PROTECTED] wrote:
Indeed it does, the issue is that writing __bobo_traverse__ methods
which try to fallback on the normal traversal mechanisms has always
been a pain (you have to reimplement the normal traversal mechanisms
yourself, including some funny
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote:
...
In our local Zope version, I implemented a solution that is
(in my opinion) superior:
Define an exception UseTraversalDefault that can be
used by __bobo_traverse__ to tell the traversal process
(either URL traversal in the publisher
--On 20. April 2006 20:29:30 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
Up to you to decide whether we may break the general rule
(no new features in micro releases) for features of this kind.
We've always included minor features that aren't obviously critical
micro release. The general
It would be very nice if we could get a list of use cases and expected
behaviour, as I hope to refactor the Zope2 traversal in the near
future and get rid of five:traversable completely.
To do this without making everybody angry, I need usescases so I can
make sure it works. :)
Andreas Jung wrote:
--On 20. April 2006 20:29:30 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
Up to you to decide whether we may break the general rule
(no new features in micro releases) for features of this kind.
We've always included minor features that aren't obviously critical
--On 21. April 2006 07:09:45 -0400 Jim Fulton [EMAIL PROTECTED] wrote:
In general, I think that new features in bug-fix releases are a bad idea.
Of course, the line between bug-fix and feature is not always crisp.
Something that is really a new feature should wait for a feature release.
On 4/21/06, Andreas Jung [EMAIL PROTECTED] wrote:
--On 21. April 2006 07:09:45 -0400 Jim Fulton [EMAIL PROTECTED] wrote:
In general, I think that new features in bug-fix releases are a bad idea.
Of course, the line between bug-fix and feature is not always crisp.
Something that is really
Andreas Jung wrote at 2006-4-19 20:13 +0200:
--On 19. April 2006 18:38:05 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
...
Do you accept it? ;-)
As release manager I don't have to dig into every problem. Patches + tests
are of course accepted if there is some consensus that a proposed
Andreas Jung wrote at 2006-4-18 20:54 +0200:
...
--On 18. April 2006 18:52:10 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
Alec Mitchell wrote at 2006-4-17 14:53 -0700:
...
Yes, it does sound like a better solution. However, the issue I see
with it is that it is essentially adding new
--On 19. April 2006 18:38:05 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
Thus, even a strict release manager might accept it.
Am I strict? :-)
Do you accept it? ;-)
As release manager I don't have to dig into every problem. Patches + tests
are of course accepted if there is some
Alec Mitchell wrote at 2006-4-17 14:53 -0700:
...
Yes, it does sound like a better solution. However, the issue I see
with it is that it is essentially adding new functionality, rather
than fixing a problem with the existing behavior. That would seem to
make it a much less likely candidate for
--On 18. April 2006 18:52:10 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:
Alec Mitchell wrote at 2006-4-17 14:53 -0700:
...
Yes, it does sound like a better solution. However, the issue I see
with it is that it is essentially adding new functionality, rather
than fixing a problem with the
Alec Mitchell wrote at 2006-4-16 12:28 -0700:
...
It seems that the way OFS.Traversable.restrictedTraverse() handles
security checking on objects with __bobo_traverse__ methods is
considerably different from the way it normally checks security. The
result is that traversal cannot obtain
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote:
Alec Mitchell wrote at 2006-4-16 12:28 -0700:
...
It seems that the way OFS.Traversable.restrictedTraverse() handles
security checking on objects with __bobo_traverse__ methods is
considerably different from the way it normally checks
Hi all,
It seems that the way OFS.Traversable.restrictedTraverse() handles
security checking on objects with __bobo_traverse__ methods is
considerably different from the way it normally checks security. The
result is that traversal cannot obtain attributes using acquisition
from objects that are
17 matches
Mail list logo
