Christian Theune wrote:
Hi,
Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
On 8/20/07, Christian Zagrodnick <[EMAIL PROTECTED]> 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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
