-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote:
> 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. I don't see how that can be: 'zope.event' hsa no dependencies[1], and provides a service which is at least as low-level (lower, in my opinion) as 'zope.schema': I can imagine *lots* of Zope3-based applications which do not use zope.schema, but *none* which don't use zope.event, zope.interface, and zope.component. > 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. I would argue that theree >>> 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. [1] Per SVN for the eggs: $ echo $ZSVN svn+ssh://svn.zope.org/repos/main $ svn cat $ZSVN/zope.event/trunk/setup.py | grep requires install_requires=['setuptools'], $ svn cat $ZSVN/zope.schema/trunk/setup.py | grep -C4 requires package_dir = {'': 'src'}, namespace_packages=['zope',], tests_require = ['zope.testing'], install_requires=['setuptools', 'zope.i18nmessageid', 'zope.interface', 'zope.event', ], Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkRy3+gerLs4ltQ4RAmByAKDbX2MRkQRAtVNi8qsiMPPYiFrFzgCfZiLj SFlJbiD2461y3f++xwSdZ6Y= =NwtU -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com