[Zope-Coders] Changes to ZPublisher

[Chris McDonough]

On Wed, 2004-10-06 at 12:34, Sidnei da Silva wrote:
> On Wed, Oct 06, 2004 at 12:29:55PM -0400, Chris McDonough wrote:
> | > Before the changes, exceptions on __bobo_traverse__ would not be
> | > handled, so if a AttributeError would happen, it would pop up
> | > untouched, resulting on a 500 response status, instead of 404.
> | 
> | Why is that a good thing?  Shouldn't it be up to the implementor to
> | decide what should happen during bobo traverse?  If an exception happens
> | that raises AttributeError or KeyError during __bt__, I don't think I
> | want it to try something else.
> 
> I suppose you are referring to the stuff below here.

It appears I misread this; you don't do getattr or getitem when you get
an AttributeError/KeyError from __bt__, that's good.

FWIW, I'm basically -1 on the publisher turning AttributeErrors into
NotFound errors even though that is the current behavior.  I recognize
that the Publisher is itself mostly DWIM but I think this case is a bit
different.  I'm not sure whether its more wrong to be inconsistent or
over-implicit wrt differences between __geitem__/_getattr__ and __bt__,
but I think I'll choose inconsistent today.

>  As for converting
> into a NotFoundError, Tres suggested to do it in ZPublisher, and
> AttributeErrors not coming from __bobo_traverse__ are converted to
> NotFound already.

Yup.

> | > It would also try __bobo_traverse__ only, if __bobo_traverse__ exists,
> | > completely ignoring __getattr__ and __getitem__.
> | 
> | What makes it desirable to use __getattr__ and/or __getitem__ if the
> | object has a __bobo_traverse__?
> 
> Simplifying __bobo_traverse__ implementation?

FWIW, I really haven't written many __bobo_traverse__ implementations,
but when I have, I haven't thought too much about how hard it was or
that it could be simpler.  I'm actually glad the framework doesn't try
too hard to help, it would have really screwed me up in a few cases
(AttributeError and KeyError seem to be pretty common).

> | > After my change, AttributeError and KeyError in __bobo_traverse__
> | > will be converted to a NotFound, resulting in a 404 response status.
> | 
> | This seems like a bit more DWIM that would need to be carefully
> | undocumented, like all the other DWIM. ;-)
> 
> The intention here is not introduce anything new, but to traversal
> using __bobo_traverse__ behave the same way as attribute traversal
> with regards to exceptions raised.

I guess the difference is that the publisher is trying to catch
AttreibuteError/KeyError/TypeError/IndexError as a result of its own
operations to *get* the object.  I don't think it was ever intended that
if you raise an AttributeError/KeyError from app code (implemented, in
this case, in __bt__) that it would have the side effect of causing a
NotFoundError.  I know that's the effect of the current code, but I
really don't think that when the Publisher was implemented that this was
ever considered.

> | > It will also continue looking through __getattr__ and __getitem__,
> | > which is where the semantics really differ. I'm more worried about
> | > changing the semantincs because there are other places where
> | > __bobo_traverse__ is used, namely restrictedTravers on OFS.Traversable
> | > and PageTemplates.Expressions.
> | 
> | I don't know if this is a win.
> 
> It's probably not, that's why I'm asking :)

Sure... 

- C