[Zope3-dev] Re: Merging schema & interfaces (was: "Sub interface")

[Jim Fulton]

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.

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

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