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 Sonntag, den 08.07.2007, 11:31 -0400 schrieb Stephan Richter: On Sunday 08 July 2007 10:02, Christian Theune wrote: Log message for revision 77624: More work on bug 98287: Introduced an event to signal that an object value is going to be assigned. Ahh, this is crazy! Why would zope.schema depend on zope.event, which depends on zope.component (if not by package, certainly by functionality)? Please revert. The solution is to rip out setting the value from within the field altogether. I promised to back out this change at EP but never got around doing it. I'd be happy to do so immediately if nobody objects. Fortunately this package is still on alpha. Any objections? Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ 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
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.fdrake at gmail.com 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
On Sunday 08 July 2007 11:38, Christian Theune wrote: Am Sonntag, den 08.07.2007, 11:31 -0400 schrieb Stephan Richter: On Sunday 08 July 2007 10:02, Christian Theune wrote: Log message for revision 77624: More work on bug 98287: Introduced an event to signal that an object value is going to be assigned. Ahh, this is crazy! Why would zope.schema depend on zope.event, which depends on zope.component (if not by package, certainly by functionality)? Because triggering an event seems to be a good way to separate concerns. This is true, but this is still just terrible. Setting the data within the field using setattr is just terrible. I know and understand the historic reasons, but Jim has argued for a long time abondoning this practice and I agree. Roger and I spent a lot of time developing z3c.form to overcome those original design flaws and to separate concerns, including data assignment and string to value conversion. This field is setting the value and I find this pattern comparable to what happens when you stick an object into a container which notifies about an ObjectAddedEvent. For me zope.schema is a very low-level package, being below zope.event. On one side we try to make dependencies more sane and on the other we add more dependencies. I care greatly about the dependencies of ``zope.schema``, because I use it for non-zope projects, such as z3c.rml. The more dependencies z3c.rml has, the more people will complain about it. 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. Then hack, and let's deprecate zope.app.form. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
