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

Tres Seaver tseaver at palladion.com
Mon Mar 20 13:50:04 EST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Shell wrote:
> 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.

So *don't use ZCML*;  use Python:  there is literally nothing which can
be done in ZCML which cannot be done in Python.  I wish that folks who
don't like / need ZCML would quit trying to dictate how the rest of us
use ZCML.

Or, if you like ZCML but don't like the current directive set, feel free
to propose a new set of directives you think are better, and implment
them in *your* namespace:  if enough other people like them, we can talk
about making people who are already using the current set change.  But
let's quit tearing up what people have alredy learned in favor of a
it-must-be-better-because-its-new variant which doesn't yet exist, and
whose improved usability we have to take on faith.

I'll note that the "Refactor mercilessly" meme from XP is *not*
particularly well-suited to frameworks / libraries:  it is best suited
when applied to *applications*, where the impacts of such changes are
borne entirely by the people who make them.  When you tear up the API of
a framework / library, you force *other* people to make changes, often
without any particular benefit to them.



Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEHvlc+gerLs4ltQ4RAkGoAJwMlUixk+yOo1wLjag8vX394zPRbgCfX8A3
9xtrj5J+Vc4Qcut51Arx3DM=
=JGRT
-----END PGP SIGNATURE-----


More information about the Zope3-dev mailing list