On 3/17/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
> You're missing the point -- the vocabulary is *not* software, and Python
> is *completely* the wrong place to define it:  it is *pure* policy.  THe
> fact that you are administering all the sites you build blinds you to
> this fact.

Sometimes they are, and sometimes they're not, depending on the
specific vocabulary.  For the simple case of a drop-down to select
from a set of known values, they certainly are policy in many cases.

> My examples move the definition of the vocabulary out into integrator /
> administratof land, which is where they belong.

For vocabularies (or sources) where the set of values really is
policy, there are a couple of approaches.  One is the CSV-based
vocabularies I implemented, which Gary has mentioned recently.  This
makes the specifc set of terms something that the site admin can
update in the database, which works well on sites which need to
support live updates within the transactional world.  It's also nice
when using multiple application servers and ZEO.

Another would be a vocabulary stored in a file that isn't updated once
the application is in production.  I'd rather see a slightly different
arrangement for this situation, where the application names
vocabularies that are then configured elsewhere.  For example, it
should be possible to provide a vocabulary by associating the
vocabulary name with a CSV file in zope.conf.

The details of a vocabulary's semantics would have to be considered of
course, even for these highly static vocabularies.  Is the title of
the term translatable?  What translation domain should be used?

There are a lot of ideas that still need to be explored in this space.


Fred L. Drake, Jr.    <fdrake at gmail.com>
"There is no wealth but life." --John Ruskin
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to