Custom DataManagers cause unexpected validator behavior

[petri]

Consider what happens when the built-in (but not used by default) DictionaryField is registered as a data manager adapter to enable storing form data in a PersistentMapping. We're assuming there's a customized getContent method returning a PersistentMapping as well of course.

Upon validation, when a context parameter (discriminator) is passed to validator.WidgetValidatorDiscriminators, it would have to be PersistentMapping (or a suitable interface, such as IMapping), rather than the content object on which the form is invoked on (the 'view context'). Likewise, the z3c.form base SimpleValidator initializes self with the same context, ie. here, PersistentMapping.

So the semantics of context change for z3c.form validation, depending on form customizations. I understand this may be by design, ie. that z3c.form considers "context" to be the (form) storage context.

Even if so, that's not documented nor obvious or intuitive. I believe it to be confusing and unexpected to most people first learning to use z3c.form, given that 'context' in the Zope/Plone world is so pervasively used to refer to the acquisition context, often the parent content object.

It would be more consistent if validation context was always assigned the content object, regardless of how form is customized (and have the from storage referenced as something else). However practicality beats purity - I would not make a backwards-incompatible change to the signature of validator.WidgetValidatorDiscriminators without a large consensus from the community.

I would therefor propose that:

• the validator be extended with a new 'content' discriminator, ie. the actual context content object (in the 'traditional' sense). This would enable discriminating against it when a custom data manager is used.
• the content be assigned to SimpleValidator instances as well, as self.content

While I realize this addition would not end the original source of confusion, with proper documentation, I believe the change would be for the better.

[projekt01]

I m pretty sure that the current implementation can do anything what you need. But you need to think a bit different about how to use the z3c.form concept. If you like to provide a form for anythig else then the object traversal context. Or let's say for a context which provides another "object" you lik to edit etc. you can simply provide a form and update/render them with your custom "content" in your view.

The context, request is a well defined concept in zope 3. The context its the traversable object where the view (page or form) adapts together with the request. It's a multi adapter on (context, request). There is nothing confusing about that.

What we often do is to write a form for manage a (context, request) and call this form in a simply browser page like:

class ComplexForm(BrowserPage):
"""Complex form"""
def update(self):
content = self.getMyContentFromSomwhere()
self.form = MoreComplexForm(content, self.request)
self.form.update()
super(ComplexForm, self).update()

def render(self):
    return self.form.render()

This allows you to separate the traversal context and the form manipulating context aka content.

I guess your problem is not a z3c.form problem, It's simply a miss match between the view traversal and form context.

Does this answer your question? Or didn't I get your question right? If so, can you explain your usecase with a small sample?

Regards Roger Ineichen

[petri]

Thanks @projekt01 - the issue is that in the scenario I describe above, to register the validator, the context discriminator that must be used is not the traversable context, and neither does it (the traversable context) get assigned as validator's self.context. Contrary to what one would expect. You could (in a way) say it's a mismatch between view traversal context and form context, yes, or as I put it earlier, changed semantics. It's a z3c.form problem because it's z3c.form validation that changes the semantics: It changes them through using 'context' to mean something else than the well-defined, otherwise not confusing zope3 (as you correctly pointed out) concept of what 'context' means.