Tres Seaver wrote:
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.
Hm. Having to separate out policy such as event sending out from the
content object does make it harder to start out with just a few classes
of mostly Python code (that do not care too much about the framework
yet) and then refactor them into more components later when the time is
there. I like being able to start out with relatively few entities in
the beginning and being able to wait and see where the pieces make most
sense later on.
I imagine this is also a pattern many beginners would start out with;
after all rich classes are the pattern in Zope 3.
While such classes do not care a lot about the framework yet it'd be
nice to allow them to send events and so on.
Anyway, I'll just have to gain some more experience building Zope 3
applications to see whether this is a real problem or not.
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
Though it's fairly easy to make content objects in charge of their own
naming by letting them implement INameChooser (they do often have to
discuss things with their container to see whether the generated name
already exists, though).
Zope3-dev mailing list