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 -- Fred L. Drake, Jr. <fdrake at gmail.com> "There is no wealth but life." --John Ruskin _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
