Stephan Richter <[EMAIL PROTECTED]> writes:

> 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.

For what it's worth, as a lowly user, zope.schema doesn't seem more
low-level than zope.event to me.  OTOH, I always end up having this
debate when I'm writing the first, lowest level components for a project
as to whether or not to introduce a dependency on zope.event at that
level or to introduce that dependency at the next level up.  So I'm very
interested in this debate.

This thread also reminds me of some other questions I've been wanting to
ask for sometime.  The first time I saw that fields had get and set
methods, I was indeed surprised.  Fields living in interfaces I thought
were supposed to describe the contracts components fulfill without
providing any implementation.  Get and set methods just seemed to
clearly to be implementation.

That wasn't the first thing, however, that surprised me about
zope.schema.  The first thing that surprised me was that invariants and
field validators were in interfaces.  On the one hand, I can see that
invariants and validators add more specificity to the contract the
schema describes.  On the other hand, there are many more times when
writing real applications that I want to validate the data going into a
specific implementation of a schema where the validations and invariante
would use implementation specific details.  Also, it just seems like
validation shoule be configurable.

Now to be sure, there are other points in these applications where I
have opportunity to write my own validation and invariant checks, but
per-field validation and per-schema invariants are such useful concepts
that encourage good separation of concerns, it seems like there should
be a way to use those concepts on an implementation specific basis
without mucking up the separation of interfaces from implementations.

I know z3c.form deals with some of this stuff at the presentation level,
but I often find myself dealing with it before the presentation level.
Maybe this debate has gone on before?  Can someone point me to it?  I'd
also love to benefit from any thoughts or discusssion on this wider


Zope3-dev mailing list

Reply via email to