Re: [Zope3-dev] Re: [Checkins] SVN: zope.schema/trunk/ More work on bug 98287: Introduced an event to signal that an object value is
On 7/8/07, Christian Theune <[EMAIL PROTECTED]> 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. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zope.schema/trunk/ More work on bug 98287: Introduced an event to signal that an object value is
Am Montag, den 09.07.2007, 10:11 -0400 schrieb Fred Drake: > On 7/8/07, Christian Theune <[EMAIL PROTECTED]> 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 ObjectField.set(). 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. Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com