Re: [Zope3-dev] z3c.form: handling of interface invariants
Am 09.10.2007 um 08:43 schrieb Michael Howitz: Am 27.09.2007 um 10:37 schrieb Michael Howitz: After thinking it over we decided to implement the first approach (change z3c.form.validator.Data to read the value of a field missing in he form on the object). We put our changes into the branch gocept-invariants. The reasons to change our decision where the following: - the second approach (using save-points) requires save-point support on the back-end and breaks without this support - using save-points would require to change the structure of z3c.form: till now the complete validation is done by z3c.form.field.FieldWidgets, using save-points validation gets split up into validation of field contents in FieldWidgets and validation of the invariants. The validation of the invariants has to be implemented at least twice: in AddForm and EditForm because saving form values is done completely different in these classes. So someone creating a direct subclass of z3c.form.form.Form has to do things again or we need additional changes in the structure. Any thoughts? As no-one had any further thoughts, I'll merge the branch into the trunk within the next few days. Done. Merged today. -- Mit freundlichen Grüßen Michael Howitz gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form: handling of interface invariants
Am 27.09.2007 um 10:37 schrieb Michael Howitz: After thinking it over we decided to implement the first approach (change z3c.form.validator.Data to read the value of a field missing in he form on the object). We put our changes into the branch gocept-invariants. The reasons to change our decision where the following: - the second approach (using save-points) requires save-point support on the back-end and breaks without this support - using save-points would require to change the structure of z3c.form: till now the complete validation is done by z3c.form.field.FieldWidgets, using save-points validation gets split up into validation of field contents in FieldWidgets and validation of the invariants. The validation of the invariants has to be implemented at least twice: in AddForm and EditForm because saving form values is done completely different in these classes. So someone creating a direct subclass of z3c.form.form.Form has to do things again or we need additional changes in the structure. Any thoughts? As no-one had any further thoughts, I'll merge the branch into the trunk within the next few days. -- Yours sincerely, Michael Howitz gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form: handling of interface invariants
Am 27.09.2007 um 05:35 schrieb Stephan Richter: On Wednesday 26 September 2007 09:06, Michael Howitz wrote: This solution requests that the back-end supports non-optimistic save-points. But we can get rid of the Data class. We'll start an implementation of the second approach on a branch of z3c.form now to show if it works. I really like the second approach, if you can get it working. After thinking it over we decided to implement the first approach (change z3c.form.validator.Data to read the value of a field missing in he form on the object). We put our changes into the branch gocept-invariants. The reasons to change our decision where the following: - the second approach (using save-points) requires save-point support on the back-end and breaks without this support - using save-points would require to change the structure of z3c.form: till now the complete validation is done by z3c.form.field.FieldWidgets, using save-points validation gets split up into validation of field contents in FieldWidgets and validation of the invariants. The validation of the invariants has to be implemented at least twice: in AddForm and EditForm because saving form values is done completely different in these classes. So someone creating a direct subclass of z3c.form.form.Form has to do things again or we need additional changes in the structure. Any thoughts? -- Yours sincerely, Michael Howitz gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.form: handling of interface invariants
Hi,
on our sprint in Bad Sulza we looked at the handling of interface
invariants in z3c.form. There we found a problem in the validation.
Look at the following example.
class IMeetingTime(zope.interface.Interface):
start = zope.schema.Datetime(title=u'start time')
end = zope.schema.Datetime(title=u'end time')
@zope.interface.invariant
def start_before_end(obj):
if obj.start obj.end:
raise zope.interface.Invalid('start time must be before
end time')
If only the end field is displayed in a form and the end date is set
to value smaller than start, the invariant does not prevent saving
the form, so it is possible to save invalid data.
This happens because accessing obj.start leads to an exception
z3c.form.validator.NoInputData which is swallowed in
z3c.form.validator.InvariantsValidator.validateObject().
Possible solutions:
- The invariant expects to get an object for checking but it gets a
z3c.form.validator.Data object which only contains the data the user
entered. So this Data object could look up the missing value on the
real object which is accessible on the __context__ attribute on the
Data object.
- Change the order things are done:
1. set a save-point (non-optimistic)
2. write the values the user entered on the object
3. validate invariants
4. If an invariant raises an exception, roll back to the save-point.
This solution requests that the back-end supports non-optimistic
save-points. But we can get rid of the Data class.
We'll start an implementation of the second approach on a branch of
z3c.form now to show if it works.
Any thoughts?
--
Yours sincerely,
Michael Howitz
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form: handling of interface invariants
On Wednesday 26 September 2007 09:06, Michael Howitz wrote: This solution requests that the back-end supports non-optimistic save-points. But we can get rid of the Data class. We'll start an implementation of the second approach on a branch of z3c.form now to show if it works. I really like the second approach, if you can get it working. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
