Philipp von Weitershausen schrieb:
Roger Ineichen wrote:
You implemented a concept which requires to write additional
python code for registration!

Wrong. I require addition python code for *creation*. *Registration* is
still done in ZCML. Please understand this difference.

Before the proposal, ZCML was able configure existing python component.

Nope. It *created* new components on-the-fly. Stopping this (because I
as many others consider this too magical) was my objective.

But on the other hand directlyProvides(..) does also some tings that I have to understand and to use as a replacement for <vocabulary ...>.

I still think it's a question of documentation.

You suggest that your "python" concept is implicit understandable
and the ZCML before was not.  I say both concept are not understandable
without documentation.

Yes, but after my proposal I only need to explain vocabularies in one
way: They're really utilities providing IVocabularyFactory. Done. I
don't need to explain a special, magical ZCML directive.

Common, explain the real use case like utlity vocabularies where
map a vocabulary name to a interface which was a abritary attribute.
That's in both case not this easy.

So far in this response I've only reiterated points of my proposal,
especially the 3 points in the *Problems* section. I will also note that
 Jim has made some pretty clear points about this discussion
two of which I quote here:

  - We need to find the riht balence between ZCML and Python.  There
    are many places where we did too much in ZCML.  Everybody makes
    mistakes. That's how we learn. :)
I didn't agree with that.

We get this mess only because of splitting the configuration declaration
 in two different implementation layers. (python and ZCML)

I think we have a different understanding of what "configuration" means.
To me, ZCML configuration essentially means setting application policy.
That includes enabling or disabling of components, making security
assertions and setting other certain information (like configuring
mailer utilities, etc.). Though it has been suggested that the latter
info shouldn't even be in ZCML, either. In any case, configuration
doesn't include the creation of components. That's Python's job.

Did you see my other mail?

The problem now is we use three different abstract development layer for configuration. (python, Zope components, ZCML)

If I speak about mix them I mean it should be possible to
register python/zope3 components without to write python code.

That's what we're doing. Of course, if the components don't exist yet,
you *do* have to write some Python code.

  - As a general rule, things should be defined in Python (or perhaps
    other definition languages) and *registered* in ZCML.  Certainly,
    "core" ZCML directives should be about reigistration/configuration
    not definition.
That's excactly the problem. Jim says "things" without to define it!

What is "things"?

Things that are to be registered. Right now there are several places in
ZCML were directives

1. create objects and

2. register them.

Jim's statement says that #1 should rather be done in Python, whereas #2
remains in ZCML. That's exactly the point of my proposal.

Yes, I absolutly understand your point. I'm only not sure if ZCML sould be a own abstract layer in our development process and has to support
the configuration at a complete concept. (without requireing pyton)

Minimal needed python application code which makes it possible to run
and test a application?


also additional python configuration code.

And please tell me where was the definition in the vocabulary directive?
The vocabulary added the option to register the arbitary attribute
well defined in the vocabulary utility class!

It's hard for me to understand a sentence that uses "arbitrary" and
"well defined" at the same time. They contradict. And, if I may add, the
"arbitrary" is actually correct. That's the problem about <vocabulary />.

If you think not and will be consistent, you have to change the
browser:page or browser:view directive and move the name
attribute to a pyhton factory as well.

That's indeed what I've been thinking about. But I tried to limit the
scope of the proposal for now. This is all explained in the "Potential
follow-ups" section of the proposal.

Please not

Perhaps you should read the proposal again, all I'm doing is referring
back to it.

I'll also state again that having this discussion now is extremely
frustrating as the proposal had been up for discussion for over a month
(five weeks, to be exact). Given that the feature freeze was approaching
and I yet have other things on my list for Zope 3.3, I needed to make
the change at some point. I even gave a heads-up before the merge so
that people could review the branch.
Sorry you didn't understand me correct. I think your proposal is good.

I only will do it in "additional" another way (like before) because I
don't like to write additional python configuration components.

I strongly believe that there should only be one way of doing this. Of
course, I can't prevent you from coming up with your own vocabulary
creation and registration directive. But I don't think Zope out of the
box should make it harder than it is for people to grasp concepts like

Ok, I understand this and can agree.

Then we can offer a second "enahnced" concept which offers additional
ways for doing it in a different way (easier or not)

Your "option" to do it in a "simpler" way is just subjectiv and for
me not true.

Everything is subjective. That's what proposals are about: express an
opinion, gather feedback and then come to a compromise regarding the


I don't know what other things to do in the future. I thought this was
the process (write a proposal, gather comments, make everyone happy and
do the change eventually). I have other things in the line, if this
process proves to be a problem, I'm pretty sure I won't have the energy
to have more discussions of this kind (the ones that come *after* I made
the change).
Did somebody agree with our proposal *before* you made the changes?

Of course. Just look through the list archives, there are several +1s,
some after some discussion, some directly.

I don't understand why I have to spend time a) repeating my proposal
over and over again and b) finding material in the list archives that is
open to everyone, including yourself.

I remember only that Stephan Richter, Dominik Huber and me not agree
at all and more then once.

For the record, Stephan Richter agreed to the whole proposal, just not
to my ammendments regarding class/factory and class/implements. That's
also what Dominik objected. I've not implemented this part and given the
opposition, I probably won't. That's the compromise.

Perhaps that's bad that we didn't post the
comment to the wiki proposal page.

Perhaps. That's not the proposal author's problem, though.

Yes, I know ;-(

I'm sure we will have to start this discussion again if we publish the
next release and other have to migrate their application.

These others had their chance. So did you or anyone else.

There's one criticism I accept: Zope 2 people will also be affected, in
the very same way Zope 3 people are. All of our discussions were on the
Zope 3 lists only (because I hate cross-posting, it's also discouraged),
so Zope 2 developers might not have been given the same chances as Zope
3 developers. That's why I'm strongly +1 for merging zope3-dev and
zope-dev, because 90% of the topics discussed on both lists nowadays
concern both parties.

I think this is a option, but we have to split relevant and not relevant
information. So this could mean ongoing discussion and proposal based discussion. To follow both at a time and get so much mails about renaming Zope 3 mixed with your important proposal mails blows me away.

but at all, thanks for your work and your intensive response.
I think adding a *own" directives namespace is right now a acceptable option for me.

Roger Ineichen
Zope3-dev mailing list

Reply via email to