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.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list