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 matter. Ross _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
