[Zope3-dev] Re: Add function for schema validation in zope.schema

Philipp von Weitershausen philipp at weitershausen.de
Mon Aug 20 10:05:23 EDT 2007

Christian Theune wrote:
> Hi,
> Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
>> On 8/20/07, Christian Zagrodnick <cz at gocept.com> wrote:
>>> I think we should add a function to validate a given schema on a given
>>> class. This should include constraints and invariants:
>> I do presume you mean object, rather than class, as your example implies.
>>> validateSchema(IMySchema, myobject)  [or alike]
>> +1
>>> I'm not sure about return values or exceptions. There are different use cases:
>>> 1. Is the object valid? -> True/False
>>> 2. What's wrong with the object -> {attribute/field-name: what's
>>> wrong}, what's wrong with invariants.
>> There should probably be a specific exception that's defined for this
>> purpose, and it could directly support the mapping interface to allow
>> detailed information to be extracted.  I suspect a common use would be
>> to simply verify the object and raise the exception in the invalid
>> case, denying whatever operation was being attempted.
>> This also suggests that there's no interesting return value; either
>> the exception is raised or it isn't.  Code that wants to introspect
>> the exception can catch that and act accordingly.
>>From my latest experience and research of when to use exceptions and
> when to use return values I'd say let's not use an exception.
> The report of "which fields are wrong" is the normal result of this
> function. Invalid data is not an uncommon output, rather, it's the sole
> purpose of this function. An exception should be raised if the
> validation could not be performed.
> The result could be a structure that lists all errors. Eventually a
> result that equals False could be used to signal no errors, e.g. an
> empty dict or an empty list.

This is exactly what I would suggest: The function should return a list 
of validation errors. Similar semantics are used in zope.formlib's 
validate() method. I agree with Wichert's objection about being a bit 
confusing, though. Perhaps a better name than "validateSchema" could 
solve this problem, though I can't think of a good one right now... 
getValidationErrors() seems to naive...

Having access to the original ValidationError exceptions (incl. the 
field name that they were thrown for) is probably all the information 
you're ever going to want (and get).

> Currently I suspect that a list as the result would be more useful, if
> we do care for invariants.  What about this:
> [(<Field xy>, u'Invalid foo'),
>  (<Invariant ab>, u'Invalid bar')]
> If the list is empty then there were no errors.

http://worldcookery.com -- Professional Zope documentation and training

More information about the Zope3-dev mailing list