zope.schema does not handle well nested object fields

[tseaver]

In https://bugs.launchpad.net/zope.schema/+bug/969350, @alexgarel reported:

Using trunk version of zope.schema, if I use an Object field whose schema has a Set (or any Collection) of Choice, it fails validating.

This is due to a bad (inexisting) handling of bind in Object field.

svn commit 112445 [1] solve the bug for the case a a Choice inside an Object, but not in the case of a Choice inside a Set inside an Object.

[1] http:https://svn.zope.org/zope.schema/trunk/src/zope/schema/_field.py?rev=112445&r1=111614&r2=112445

And supplied a patch: https://bugs.launchpad.net/zope.schema/+bug/969350/+attachment/2968618/+files/zope.schema.bug-969350.patch

describing it:

I propose a solution which handles binding not only validation.

There is a difference with previous code : it does not bind inner Choice to Object value but to Object context.

I prefer this solution since binding to value maybe problematic in a lot a cases, eg. when vocabularies depends on object situation in the object tree whereas most of the time, at creation, Object value is not yet tied to any context.

I precise last point for eventual discussion:

The main point is that my fix propose to bind Object field (as its done for collections, or vocabularies) but it introduce a difference with previous behaviour (itself shipped with 3.6.4)

Previously, a Choice field nested in a Object field gets bound to the new value to be assigned to Object field at validation time.

In the fix that I propose. I bind the Choice to the same context as the ObjectField.

This fix which handles Object.bind feels more general to me than an exception in _validate_fields for Choices. It already solves the problem of binding nested Set fields, and will permit a better handling for third party fields which need binding.

I also prefer this solution since binding to value maybe problematic in a lot a cases, eg. when vocabularies depends on object situation in the object tree whereas most of the time, at creation, Object value is not yet tied to any context.

[jamadden]

I also agree that binding to the original context seems more correct. I think this is closer to what happens when using a FieldProperty.

[jamadden]

I also agree that binding to the original context seems more correct.

However, that would be backwards incompatible at this point. (Although no tests failed when I tried binding to the context instead of the value.)

I think we can still get all the same basic advantages by binding to the incoming value (in fact we should have an extra degree of freedom at that point, as the field's context and the value are separate).