[Zope3-checkins] Re: [Zope3-dev] Re: [Checkins] SVN: zope.schema/trunk/ More work on bug 98287: Introduced an event to signal that an object value is

Christian Theune ct at gocept.com
Tue Jul 10 02:50:15 EDT 2007

Am Montag, den 09.07.2007, 10:11 -0400 schrieb Fred Drake:
> On 7/8/07, Christian Theune <ct at gocept.com> wrote:
> > > Please revert. The solution is to rip out setting the value from within the field
> > > 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.

I don't think it would be a lot of overhead as it's only for

I'm going to revert my change for now and take the time at EP to think
about how to solve this with me staying happy.


More information about the Zope3-Checkins mailing list