On Thu, Apr 07, 2005 at 10:06:38PM +0200, Philipp von Weitershausen wrote:
Albertas Agejevas wrote:
Currently, in the generic case, Zope 3 raises a ComponentLookupError in zope.app.publication.http line 74, and a 500 response is served.
I can't find that particular line of code. Are you talking about HTTPPublication.callObject where it looks up the view (zapi.getMultiAdapter) which might result in a ComponentLookupError in case the adapter can't be looked up?
Sorry, I had a dirty sandbox. Yes, I was talking about that line.
Well, maybe that should change then. These views could easily raise MethodNotAllowed, couldn't they? If they can't find the necessary adapters, the their functionality is obviously not available and they should raise an appropriate error.
They could, but the problem is with introspection of which methods are availble, for the mandatory Allow: header.
Ah. Dang.
Well, we have a sort of analogy to this for metadata. Views needing annotations are not registered for * but for IAnnotatable, so those views always work because they work with objects that promise something by marker interface.
So, to compare, we might need the concept of a "filesystem representable" object. That concept would stand for "you can get IReadFile/IWriteFile adapters for that object"; so, those HTTP views needing filesystem representation adapters would only be registered for filesystem representable objects, and that would obviously always work.
In any case, the current fact that we sort of promise a method on an object and then don't keep that promise is not okay.
Philipp _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
