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

[Tres Seaver]

-----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          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://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-----