[Zope3-Users] z3c.form: LookupErrors

Tue Apr 7 22:48:31 EDT 2009

Hi Martin

> Betreff: Re: [Zope3-Users] z3c.form: LookupErrors
> 
> Hi Roger,
> 
> >> What if your list of choices depends on constantly 
> changing data? For 
> >> example, a widget allows you to select a user from a userfolder. 
> >> Later the user gets deleted.
> > 
> > pang, legacy data created
> 
> In the real world, this type of of thing happens all the 
> time. It's incredibly unhelpful to say that this results in a 
> user-alienating traceback and no means of fixing the data 
> through the web.
> 
> Are you proposing that every time a user is deleted, we run a 
> script over all content in the site that needs to know all 
> the objects that may use a user source for a choice field, 
> and modifies it? That's not just prohibitively expensive, 
> it's open to an incredible number of permutations of things 
> that may or may not need to be migrated in an open-ended 
> system such as Plone.

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

> >> I totally agree with Martin that we should use 
> missing_value in those 
> >> cases.
> > 
> > Defently not. Such forms will show you a default value and 
> you think 
> > this is Ok. But the object devliers still the old stored 
> value. Pang, 
> > pang and you will be surprised till you will start 
> debugging and see 
> > the real value decorated within the missing_value. That's a 
> horrible 
> > scenario!
> 
> It'd be nice to show what's happened, e.g. with a validation 
> error on the form. A traceback is definitely not the right thing.
> 
> >> I think this could actually be considered a fairly serious bug.
> > 
> > No, defently not, the Choice field defines what are valid 
> values and 
> > the widget only handels that. There is no reason why a 
> widget should 
> > do more then that.
> > 
> > If you remove valid values for a field, you also have to make sure 
> > that the system doesn't use them. Doesn't matter if a 
> system can work 
> > with different/legacy data or not.
> > 
> > I think you are right that a valid missing_value should get 
> used, but 
> > that must be implemented at the field level. The field has 
> to return 
> > that missing_value. This will make sure that objects value 
> returns the 
> > same as the widget does.
> > 
> > But that's a kind of auto-mirgation for legacy data.
> > And I'm not sure if this is a good idea.
> 
> Let me put it this way: If we are to use z3c.form in Plone, 
> the current behaviour or any solution that depends on 
> site-wide migration of data in this kind of scenario is a 
> showstopper. We'd need to customise pretty deep parts of 
> z3c.form in the best case or ditch it in the worst case.
> 
> But it sounds like Stephan agrees. :)

Ok, let's solve that problem but let me give an example
which we should discuss first.

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.

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?

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

- 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.

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.

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.

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)

Hm,
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.

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?

Regards
Roger Ineichen

> Martin
> 
> --
> Author of `Professional Plone Development`, a book for 
> developers who want to work with Plone. See 
> http://martinaspeli.net/plone-book
> 
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
> 