[Zope3-dev] Re: Merging schema & interfaces

[Peter Sabaini]

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.

So far its been working out ok...

  - peter.


> This has been on my unofficial to-do list for some time.
> It just needs a volunteer. :)  (It's not on the official
> to-do list because we haven't actually needed it yet.)
> 
> Jim
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3461 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040302/859ea884/smime.bin