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.

> 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.

>> 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.

> Note:
> 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.

> Minimal needed python application code which makes it possible to run
> and test a application?
> or
> 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.

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

> 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.

> btw,
> 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.


Zope3-dev mailing list

Reply via email to