On 8/4/05, Alec Munro <[EMAIL PROTECTED]> wrote:
> We want to allow a choice field with an "other" option, that allows
> them to type in an arbitrary value. So far, we have this working up
> until the point of validation. At the point of validation, it notices
> that the other value is not in the vocabulary, and raises
> ConstraintNotSatisfied.
> My initial thought is to create a new field type for
> "SuggestedChoice", that simply doesn't perform the checking against
> the vocabulary values. Has anyone else run up against this?

I haven't dealt with this, but have a bit of a suggestion as to an
approach you can take.  The details will vary depending on whether you
want the added values to be shared across all instances or only be
available on a per-object basis.

You'll need to use a named vocabulary, so the factory will take the
context object as an argument.  This allows you to construct the
vocabulary based on the common values plus the values added.  A custom
widget for your vocabulary would be responsible for managing the added

If the added values should be specific only to a particular content
object, you can use an annotation to store added values, or simply
decide that values present on the object are already considered valid
(since you allowed them at some point), and maintain anything added
but not applied yet within the form fields.

If the added values should be shared among all instances of the field,
you can use a local utility that provides IVocabularyFactory to store
the set of allowed values.  This would also give you someplace to hang
UI that supports determining the full set of allowed values and
perhaps editing supplemental data (for example, if the field values
and presentation are separate).

The later would be particularly interesting if you want values that
are I18N messages and have the translations stored in the utility.


Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation
Zope3-users mailing list

Reply via email to