Tres Seaver wrote: [snip]
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 wraps them).
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).
Regards, Martijn _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
