[Zope3-dev] Proposal: Vocabulary Fields

[Guido van Rossum]

> Martijn wrote:
> >>> I still disagree with this multiplication of entities; we now have 
> >>> fields and enumerated fields while before we just had one kind.
> >>> I still haven't seen a motivation for this.
> 
> 
> Guido wrote:
> >> Isn't there a way to make the "enumerated" part an option, like
> >> min_size and required, rather than a new type?
> 
> Steve wrote:
> > Yes.
> > 
> > I explained this in my earlier email to this list and to Fred.
> > 
> > I'll try to dig out the reference from the archives.

And Steve wrote also:
> http://mail.zope.org/pipermail/zope3-checkins/2003-April/008335.html
> 
> So, it wasn't this list.
> 
> Here's the relevant part:
> 
> 
> ----
> (SteveA)
> I was going to make a similar change to this field type.
> However, rather than make a different implementation class, I was going
> to use the same implementation class, and have instances change their
> own interface declaration depending on whether allowed_values is defined.

Maybe it's too early here; I'm not sure I understand.  An example
might help.  Or maybe I shouldn't be in this discussion, as so far I
only have a very limited understanding of Schemas and fields!

> This allows you to use a different widget for an any-values fields to
> the one used for an allowed-values field.

That seems essential to me; for an unconstrained field I'd expect a
plain text box, while for a constrained field a drop-down menu makes
more sense (except if the constraining set is very large or too
dynamic to know in advance).

> Other than this change of constraint, I see no problem with the same
> implementation being used. I see no more problem with changing an
> allowed_values constraint on a Field instance than with changing any
> other constraint on a Field instance.

Does this mean that you propose to allow also changes e.g. to the
'required' or 'min_size' attributes of a field after the interface has
been declared?

> (Quote from Fred)
>  > As I'm sure you understand, the biggest aspect of schema change is
>  > proper support for the new schema in the application, and when
>  > expanding the set of allowed values for a field, the hardest part is
>  > ensuring the code has been tested thoroughly and that edge cases are
>  > properly located and checked.  There's far more than making a couple
>  > of edits to spelling of the schema.

Alas, out of context I don't understand.  I'll ask Fred for a
clarification once we're together in the same office, later today.

> (SteveA)
> Do you propose disallowing any other changes to the notional set of
> valid values for a field?
> 
> Do you want Field instances to be immutable?

(Guido)
It never occurred to me that there would be a use case to modify a
Field instance after the interface has been created.

Which means, I guess, that if the set of allowed values is not known
when the schema is defined, that set needs to be maintained
differently.  I certainly see a use case where two objects of the same
class, implementing the same interface, must be allowed to have
different sets of allowed values.  This set must be maintained outside
the schema field, which is shared between the instances.  Maybe the
widget instance used to render and input the field is the right place?

Now I regret not having read Fred's proposal...

--Guido van Rossum (home page: http://www.python.org/~guido/)