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@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users > _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users