[Zope3-Users] z3c.form: LookupErrors

[Martin Aspeli]

Hi Roger,

 > I agree that this should not end in an error blocking the UI.

Good. :)

 > Let's say you have a Choice with possible values defined in
 > a source, vocabulary or a simple list like:
 >
 > ['please select', 'Max', 'Peter', 'Fred', 'Admin']
 >
 > And we have a field which looks like:
 >
 > ownership = zope.schem.Choice)
 >    title=u'Ownership',
 >    values=['please select', 'Max', 'Peter', 'Fred', 'Admin'],
 >    missing_value='please select',
 >    required=True,
 >    default='Admin')
 >
 > Now an object get added and the ownership value
 > get set to 'Peter'.
 >
 > After that 'Peter' get removed from the system.
 > Now it's a question how the system is built.
 > In some case an event get fired (user removed)
 > and you can deny removing the user because
 > one or more objects still need the user.

In a relational database, this is a lot easier. I think for most
content scenarios using the ZODB, it'll be tricky to maintain these
links except on a case-by-case basis. In that case, of course, this is
all a non-issue.

 > I agree that this is not allways usefull because
 > of performance reason. If so we have to live with
 > legacy data.
 >
 > - What does this mean to the form or the widget?
 >
 > - What should the widget show for the above use case?

On a display form/view it should probably show the stored value, maybe
with a warning.

On an edit form, it should show the field with a validation error
message and the missing_value selected. If the field is required, the
user will be forced to choose a new value. If not, at least they
will've been warned.

 > - What does the object return till someone will
 > adjust the ownership (widget) value.

By default, the old value. That's what's stored. You can't always
check against the source unless you use field properties and are
willing to take that hit.

It's also probably going to be useful to know what the erring value
was, so it needs to retain that for the validation error.

 > - And much more important, depending on the form,
 > does the user know that he has to adjust the
 > ownership value or does the widget, based on the
 > legacy value handling, show something that the
 > user think it is ok and he doesn't adjust the
 > ownership value at all?
 >
 > I think this use case can only get fixed if the
 > underlaying field, e.g. FieldProperty which manages
 > the ownership value will be consistent within the
 > widget.
 >
 > Which means the FieldProperty should only use
 > and return known values defined in the field.

Maybe. I'm not sure that's going to fit all use cases.

For example, let's say you're asked to pick a person as the "original
creator" of a document. To make it easy, we may use a form with an
auto-complete widget against a user source. If that source no longer
has the value, the historical information about which user was chosen
is still important.

Archetypess has the notion of en enforceVocabulary property that can
be set to False to allow values outside the vocabualry. This becomes a
schema decision, effectively.

 > In the usecase above, the field should only return
 > 'Admin' or 'please select' but not 'Peter' which got removed.
 > Hm, I'm not even sure if missing_value or the default value
 > should get used.

Probably missing_value if you want the user to re-select.

 > Since the missing_value is only a indicator that no value
 > is given, this means if a field defines required=True, then
 > the object isn't valid if you whould validate within the
 > object schema.

Yep, you'd effectively force the user to re-select.

 > Probably the 'default' value is the right value to use
 > for removed values in some use case, in other usecase
 > probably not. (not sure about that)

Yeah, it's tricky.

This is also why z3c.form (and other libraries) need to have some
leniency built in for cases where data integrity isn't 100%. Warnings
are good. Errors are bad.

 > Probably this is just to much and we should just adjust
 > the widget and use other field/widgets implementations
 > which handle this use cases in different ways.

Probably. You can then make a policy decision when you define the schema.

 > My recomendation for solve this problem:
 > A Choice field should never return something else then
 > defined in it's source.
 >
 > Any reason why this whould be a bad idea?

Yes - see above for the case of historical data, for example.

What I'd like to see:

  1) z3c.form catches the LookupError and treats it as a valdiation
error (even on first render of the form), not a fatal error

  2) z3c.form defaults to missing_value if there is a LookupError
against what the data manager returns. The value is indeed "missing in
action"

  3) If possible, we output the offending value in the error message

  4) In use cases where it makes sense, people can use a field property
implementation that checks the source and returns the default (or
something else) if the value can't be found. That's not for z3c.form
to decide or depend on though.

Martin