Martijn Faassen wrote:
Jim Fulton wrote:
- Implement ILocation in your content objects. This is the simplest
course. It sounds like, for your application, the content objects
should know about their locations, since you want them to be able to
generate events that contain location information.
Right, and we ended up doing so. Not doing so was a mistake (and my
fault). I just thought after the debugging session that it's a bit of a
dead chicken to have to provide the interface to make the catalog work
as expected. It took quite a bit of hard thinking to understand what was
really going on, as everything else appeared to work. This is not a good
thing a programmer has to deal with.
A scenario that could easily happen is the following:
* an application is built, and IContained is not implemented.
* users add lots of content objects.
* now in a new iteration of the application, it's decided to add catalog
* now (after debugging why cataloging appears to fail mysteriously) the
programmers discover they have to go back and somehow get rid of the
ContainedProxy wrappers in the ZODB.
- Don't generate events amout the located objects (e.g. modification
events) from within content object methods. The content objects don't
have enough information. Rather, generate the events from views on
the objects obtained from the container.
Right. I just think it's not very programmer-friendly to have the
catalog fail silently because IContained is not being implemented. I
wish there were some way to make the catalog either not fail, or
alternatively fail noisily. I haven't thought of such a way yet though,
but it'd be nice. Proxies making ones life difficult smells a bit too
much like Zope 2. :)
I agree. Proxies suck and should be used as little as possible.
ContainedProxies are a compromise between two goals:
- Don't make content components do anything
- Don't use proxies. :)
We don't want to *require* objects to provide ILocation.
I don't know what the right answer is here. I'll think about it. I'd love some
I'll note that a common model for Zope 3 is to have content objects that don't
participate in the frameworks much. Rather, the adapters participate in the
framework and we arrange that the adapters get the ContainedProxy objects. This
has worked pretty well in my experience. I've observed that as soon as a
object wants to participate in the framework, that it wants to be a location.
I'm not sure if this is good or bad, although I do find it a bit disquieting.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list