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

[Tres Seaver]

-----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          tseaver at palladion.com
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-----