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

[Gary Poster]

Jim Fulton wrote:

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

We have that now, yes?  We're using it.  The guts are in Zope 3, from 
when Jim and I pair programmed on it quickly a few weeks ago.

Zope 3 needs a pattern on how to use the output in forms, and we need to 
figure out how to spell the invariants and possibly build a library of 
these.

We have a first stab on how to do this.  One of our interfaces has

     invariant(isGreater(
         "expiration_date", "publication_date",
         _("${field1} must be later than ${field2}")))

And then we have form machinery that calls all invariants.

The invariant stuff is very generic and I would have put it in Zope 3, 
except that what we have is definitely in the "cooking" state.  We're 
putting stuff in Zope 3 proper only if we have community consensus or 
papal blessing.

Rendering it in a form is also something that I'd like to put in Zope 3, 
but our form machinery has forked for a while (and it's trivial to do 
anyway).

Perhaps after the zope 3 repository has changed its structure and we 
have all of the dependency management and so on we can create a 
zc_experimental package or something like that so people can look at the 
"cooking" Zope 3 stuff that we're doing, debate it, improve it, put it 
in Zope 3 proper or not, and so on.  That would be great.

A final point: the cross-field invariants might be the best we can do 
for these sorts of issues, but its worth noting that vocabularies 
sometimes want to be driven off of the object, if available.  We're 
generally calling that a "bad schema design" :-) and reworking the 
schema in these cases.  We do have some fragile registration 
vocabularies that rely on the bound context behavior of edit and add 
forms--an edit form binds the object and an add form binds the 
adding--but these only care about the value on the same field, not all 
the values of the object.  It's still fragile and problematic, though.

Gary