[Zope3-dev] Proposal: Vocabulary Fields

[Fred L. Drake, Jr.]

Martijn Faassen writes:
 > First I thought you were introducing a third category of field next to
 > non-enumerated and enumerated, but if I understand the proposal correctly 
 > there would just be one new field, the VocabularyField.

That's correct.  It would actually be possible to turn all
"enumerated" fields into vocabulary fields using suitably defined
vocabularies.  I don't know whether doing so would be desirable.

 > >   A vocabulary may be provided by some object in the ZODB, a query to an
 > >   external database, the contents of a file maintained by another
 > >   process, or static data provided by a separately maintained piece of
 > >   code.
 > 
 > Why such a restricted dynamism? Are we going to introduce a new set of
 > classes if people want 'required' state to be dynamic?

These were intended as examples; I've tried to clarify that in the
proposal.

 > The approach I took in Formualtor is to allow (on any field) a way to call a 
 > method to get the value of a field property, instead of getting it
 > statically from the field itself. That way you allow the dynamism of
 > *everything*, when the user so requires. Fields already have a way to get
 > bound to objects which can be used this way (see the bind() method).
 > The form code does this for you.
...
[long example]
...
 > This approach is simple to use, it allows other field properties to
 > behave dynamically as well, and the interface actually states clearly
 > that a field is going to be dynamic.

Neat, but scary.  There's a lot to swallow here.

One thing I like about the use of a registry is that the source of
vocabularies can be specified in ZCML, so can be changed by the site
developer; that's more painful if content objects need to know about
vocabulary sources.

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

 > the vocabulary data and not the field itself, but this still seems the
 > responsibility of the widget displaying the field, not the field itself.
 > One question would be how to accomplish some of the same functionality
 > you propose in the presentation components in my proposal. Then again,
 > you punt on how this is going to hooked up to forms as well. :)

That's 'cause I'm still figuring this out.  ;-)

 > Two new registries (one for vocabularies and one for presentations) added
 > to the system for this functionality also seems worrying.. This requires
 > quite a few registrations of things before you can actually start to use
 > a VocabularyField, which may be a usability issue.  

Perhaps.  I've modified the proposal to only include one (the
vocabulary registry), which mitigates this issue somewhat.  The
vocabulary registry is still used, and I'd expect the registry used in
Zope to take advantage of ZCML and the component architecture.


  -Fred

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