[Zope3-dev] Re: Merging schema & interfaces

[Jim Fulton]

Peter Sabaini wrote:
> Jim Fulton wrote:
> 
>> Derrick 'dman' Hudson wrote:
>>
>>> On Tue, Mar 02, 2004 at 10:10:34AM -0300, Sidnei da Silva wrote:
>>> | | On Mon, 01 Mar 2004 10:05:08 -0500
>>> | | Jim Fulton <jim at zope.com> wrote:
>>> | | [..]
>>> | | > There is a separate schema package because schema are much 
>>> newer than
>>> | | > interfaces. It's a packaging issue, not a technical issue.  I'm 
>>> open
>>> | | > to merging the schema package into the interface package at some
>>> | | > point.
>>> | | Now that the subject came up, I would like to ask your opinions on
>>> | improving field constraints a bit, so one can have a bit more context
>>> | (like the object bound to the field for example). What do you think?
>>>
>>> +1
>>>
>>> I think this is essential.
>>>
>>> Imagine you are creating a contact, as in Jim's tutorial slides.  The
>>> contact has a city, state and zip code (in the US).  Without this
>>> context, someone could enter the address "Rochester, NY 60123".  Zip
>>> code 60123, however, is for Elgin, IL.  If need be, I could dig out
>>> several other real-world situations where the valid values for one
>>> field depend on the value set in another.
>>
>>
>>
>> Yup, this is the classic reason why someone would want this, *but*:
>>
>>> This does bring up the issue, though, of order of evaluation.  Perhaps
>>> a field could have two constraints - the first is applied only to the
>>> pending value of the field, the second has access to all the pending
>>> values.  All context-independent constraints are evaluated before any
>>> context-dependent ones are.  This way a field can have an independent
>>> sanity check that must pass before any other fields' context-dependent
>>> constraints see the value.
>>
>>
>>
>> This road leads to madness. I know, I've been down it before. :)
> 
>  >
> 
>> I've come to the conclusion that it is a mistake to try to deal with
>> relationships between multiple fields in individual field constraints.
>>
>> To deal with constraints on multiple fields, we will add the ability to
>> model interface/schema-level invariants/constraints.
>>
>> def cityStateZip(contact):
>>     pc = lookupPostalCodeFor(contact.city, contact.state)
>>     if pc != contact.postal_code:
>>        raise InvalidPostalCode(contact)
>>
>> class IContact(zope.interface.Interface):
>>
>>    postal_code = ...
>>    city = ...
>>    state = ...
>>
>>    invariant(cityStateZip)
>>
>> Then, when we modify a contact, we can check individual
>> field constraints *and* we can check the interface-level invariants.
> 
> 
> FWIW,
> 
> I dont know about madness (and anyway, the little green martians dancing 
> around me tell me not to worry...), but I've implemented something not 
> unlike this just now. The neat things (IMHO) about this:
> 
> * every attribute has a stack of 'Validators'
> 
> * Validators are constraints and operations on them (AND, OR, NOT)
> 
> * Validators are evaluated in a RPN-like notation
> 
> That way, one can create pretty flexible expressions, both on the 
> attribute and schema level.

Are yuou saying that the validators use the values of multiple fields?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org