[Zope3-dev] Re: interaction between LocationProxy and IIntId utility

[Martijn Faassen]

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