Hi Martijn and Dieter!
Martijn is correct, absolutely!
At my product __bobo_traverse__ is calling __call__ method who do the dirty
How could be the __bobo_traverse__ to work as expected with out losting
I can't return self without losting traverse_subpath list and that's because
I don't return self to execute __call__ (index_html returns __call__ too)
2007/3/26, Martijn Pieters <[EMAIL PROTECTED]>:
On 3/26/07, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Martijn is a Five expert and told you things that may happen
> when Five is heavily used.
Not as much as the other one though. ;) I (Martijn Pieters) attempted
to help out, Martijn Faassen is the Five expert.
> I do not think that your problem is Five related -- and I am
> almost convinced that it is not related to your wrappers.
This is not a Five problem.
> Unfortunately, I cannot tell you what causes your problem.
> It seems to be authentication related.
> I would verify "REQUEST._auth" (you told us, you were using
> HTTP basic authentication; then "REQUEST._auth should contain
> the authorization info from the request) in your debugging session.
> One potentially important hint from Martijn is to check
> where the failing "validate" is called. If the call comes
> from traversal, then authentication did not yet happen (as
> Martijn has pointed out).
I suspect that he is doing something at traversal time that requires a
logged-in user. The publisher, however, won't look for a user until
1) Traverse the URL
2) Look up user in the returned context
3) Call whatever traversal returned
If his __bobo_traverse__ returned a callable that does the dirty work,
the problem should be resolved. Compare this to Five views, for
example. They are objects with a __call__ method. They are constructed
at traversal time (__init__ is called), and then called (__call__ is
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -