[Zope3-dev] Re: a plan for widgets?

Jeff Shell eucci.group at gmail.com
Mon Mar 20 13:37:01 EST 2006


On 3/17/06, Tres Seaver <tseaver at palladion.com> wrote:
> Jeff Shell wrote:
> > By the way, isn't it pretty easy to provide straight up values anyways
> > for those quick drop-down situations?
>
> <snip Python example>
>
> 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.
>
> My examples move the definition of the vocabulary out into integrator /
> administrator land, which is where they belong.

No. I think they are software. Or can be as much software as anything
else. Sometimes I don't care what the values I get for a Choice field
are. Sometimes I care very very very much. With the interfaces,
vocabularies can come from a lot of sources. Personally, if I were
giving someone an editable vocabulary list in text because they were
an 'integrator/administrator', I'd write a Vocabulary object that used
something like YAML. Or CSV if that's what the user that's meant to
maintain it is. But I'm not going to turn over site.zcml or
overrides.zcml with all of its other crap just to let a secretary add
an airport code to a "preferred destinations" vocabulary.

There's nothing in the Zope 3 implementation stopping you from having
the definition come in from outside. But don't restrict me from using
Python just to make a bone stupid simple list of values when I have
100% or even 80% surety that it's *not* something that needs to be an
editable policy. It's a waste of time, it's another layer of
confusion, and as I said above: this is another policy thing that may
not even be maintained by any 'administrator/integrator'. So if there
was just one concept of a registered Vocabulary: that of a named
utility providing the IVocabulary (or a derivative) interface, then
it's easy: write one for your integrators/administrators that sources
itself from ZCML, OPML, RDF, whatever. I don't need it. For me, it
becomes a maintenance nightmare, or just a roadblock early on.

So maybe I am blind. But I **absolutely do not need to worry about
integrators/administrators**. And I absolutely hate wasting time
writing something that hurts me to write and maintain for a role that
I, nor my colleagues, nor my customers, really have to play. Maybe you
do. But then, you should do like I do and build yourself some
frameworks on top of Zope that suit your world, your customers needs,
etc, and work through those. Don't make me have to jump through hoops
and XML pain just to make a "yes/no/maybe" option list just because
there's this theoretical person out there that might want to add a
"maybe not" after they find it buried deep within the trenches of XML
files buried in an Egg.

--
Jeff Shell


More information about the Zope3-dev mailing list