-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
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 functionality.
* 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.
or
- 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
and
- 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
good suggestions.
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 content 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
I find the same pattern creeping into my work: content objects need to
be policy free, which means that they can't do things like emit
events, because whether and when to emit them is policy. For
instance, if your content objects have setter methods (or properties as
sugar on top of them), such methods can't know whether they are the
only / last one to be called for a given interaction, and therefore
whether they can safely / efficiently emit a modified event.
Likewise, content objects don't seem (to me, anyway) to know enough to
handle their own renaming; rather, such handling needs to occur in
conjunction with the container (and perhaps the ContainerProxy that
wraps them).
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCzdmO+gerLs4ltQ4RAmZ3AKDLyjDIWRT9dWjrOvawzk3GzhcfVwCfVw97
Ap2CwXs1eG5ApYwwTb1U/ys=
=/69O
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
