[Zope3-dev] Proposal: Vocabulary Fields

[Fred L. Drake, Jr.]

Martijn Faassen writes:
 > But presumably your examples are only about allowed_values, and not about
 > other field properties, right?

Yes; vocabularies are all about allowed values.

What other field properties do you think are interesting in this
context?  I suspect most other constraints are (potentially) subsumed
into the vocabulary itself.

Properties like "default", "readonly", "required" are still valid.
"min" and "max" on Orderable can be subsumed, but there may be value
in exposing the constraints to advise an interactive user; the same
can be said of "min_length" and "max_length" on MinMaxLen.

"value_types" and "key_types" on the container types could be
expressed as vocabularies, but that's really not the intended
application.  I'm not proposing that.

 > That's true. On the other hand, vocabularies generally do have something
 > to do with the content object or at least the context of the content
 > object. Perhaps you can come up with some examples on this how this
 > would work? For instance, one could have 'apparel' objects which have
 > a selection of 'colors' or 'sizes', but this can be different for each
 > particular instance.

Yes, there is a tie, but sometimes it's fairly weak.  We could
definately have common vocabularies for various types of postal codes
or other information derived from external authorities (governments,
standards bodies, etc.).  Several unrelated content objects may
benefit from the same vocabulary, and the entire application may
depend on these types using a single vocabulary for all of them
(especially if different sources normally update with different
frequencies or levels of reliability).

At other times, the vocabulary needs no more than context information;
the object itself isn't really relevant.  An example of this would be
child/sibling selections.

(The VocabularyRegistry information may need more explanation in the
proposal.  The preliminary, non-Zope-specific implementation I have
passes the content object to the vocabulary factory, so a "siblings"
vocabulary can be constructed based on the content object.)

 > >  > Worrisome in the proposal as well is the inclusion of presentation 
 > >  > information in the field. Now I understand this is only presentation of
 > > 
 > > There was definately some lack of clarity in the proposal; my
 > > preliminary implementation allowed the presentation to go unspecified,
 > > which caused a default presentation for the vocabulary to be retrieved
 > > from the presentation registry.
 > > 
 > > That's no longer an issue, since the presentation stuff has gone.
 > 
 > What would replace this facility? I did think it was interesting to
 > be able to define things like sort order and display name versus
 > internal name.

The new flavor of the proposal add "term" objects; these would be
responsible for providing metadata for a vocabulary item.  For
example, a term for a state has a "value" attribute (all terms would
have this) which gives the concrete value of the field for that term.
Additional attributes/methods can be provided that widget
implementations could use; for the states example, I gave it a "title"
attribute which holds the full name of the state.  Presentation code
can decide how to properly present such things; marker interfaces can
be used on fields/vocabularies to aid in dispatching appropriately.

 > Perhaps some concrete examples of use cases would help us out flesh
 > out the details.

Definately.  I'm not directly involved with the application driving
these issues, nor am I in the same office.  I'll see what I can do,
given the availability of time from the relevant people.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation