Florent Guillaume wrote:
Dominik Huber wrote:
The modification descriptiors were introduced by Uwe Ostermeier to
handle the versioning and cataloging stuff. I'm not an expert in that
field, but in my understanding the modification descriptors are more
general and your case is a subset that could be handled with them. As
a developer, I would still prefer one concept, because it's easier to
adapt. Sufficiently fundamental cases are always a shaky
discrimination to differ two concepts for future implementation
decisions.
If you don't feel that containment boundaries are a sufficiently
fundamental concept, then we have a strong disagreement.
An object modified event consumer such as a versioning or cataloging
tool should handle modifications. In that respect the handling of
ordered contaiment isn't more fundamental than handling of other
ordered sequences and all use cases covered by modification descriptors
today.
I stand by what I checked in.
IMO such a design decision would require a proposal :)
And BTW with "modification descriptions" I couldn't write a simple
adapter for this. I'd have to have a generic adapter for
IObjectModifiedEvent, then iterate over all the descriptions and
filter by hand. Yuck.
OTOH, it is pretty hard for versioning or cataloging tools to guess
derived subtypes of IObjectModifiedEvent and handle them generically.
So, we still have to introduce kind of a mechanism similar to the
modification descriptors to decouple our components.
Perhaps the solution might be at least a mixture of both concepts. So we
can derive subtypes *and* provide additionally modification descriptiors
too. But then we would need - like Jim mentioned - a general strategy
for modification descriptions..
1. Sequence modification description:
a. Sequence(IOrderedContainer) without any keys.
2. Dedicated modification descripton for the container framework
???
3. Attributes modification description:
a. Attributes(IOrderedContainer, 'updateOrder')
b. Attributes(IEnumerableMapping, 'keys')
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
