On 7/8/07, Christian Theune <[EMAIL PROTECTED]> wrote:
> Please revert. The solution is to rip out setting the value from within the 
> altogether.

Humm. Ripping out setting the value from within the field doesn't make
sense to me. The field is the only demonitator between zope.app.form and
zope.schema that I could find to make this happen reliably and IMHO
without hacking.

I don't know if there's a single "right" way to deal with this, but I
don't think changing this helps with the idea of firing events for
setting an attribute (what I first reacted to on this) or the original
bug report cited in the commit message.

I don't see the value in having a general notification on every field
assignment; I'm sure lots of dispatch optimizations kick in, but I
can't see how this won't have a noticable negative performance impact.
If dealing with a particular assignment is important, the specific
properties should probably be firing interesting events when set.
This means they need to be implemented to fire events if they're
interesting, but I'd rather have to do that than have the framework
grow unhelpful overhead for basic field assignments.


Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to