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


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

Reply via email to