[Zope3-dev] Re: Vocabulary the next proposal

[Roger Ineichen]

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
>>> (http://mail.zope.org/pipermail/zope3-dev/2006-February/018265.html),
>>> 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)

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

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

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

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

;-)

>>> 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 ;-(

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

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.

Regards
Roger Ineichen