[Zope3-dev] Re: Vocabulary the next proposal

[Philipp von Weitershausen]

Roger Ineichen wrote:
> 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.

Yes, but even with the directlyProvides() thing, you only have to
document ONE thing. I can now write in my book:

  "Vocabularies are registered *and* looked up as utilities providing
  IVocabularyFactory."

Wow, that's pretty clear. Someone understanding utilities will now
*immediately* understand how vocabularies are to be registered and
looked up.

To compare, look up Chapter 16 in my book. See any explanation of the
magical <voculary /> directive and why it's looked up via
IVocabularyFactory? No, I chickened out of it because it's just too darn
complicated to explain!

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

The rule "define things in Python, register them with elementary
directives in ZCML" sounds INSANELY easy to me.

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

That's indeed the *key* question. I think Jeff Shell has made some very
good points in
http://griddlenoise.blogspot.com/2006/03/zcml-needs-to-do-less.html, his
main message being: ZCML attempts to do too much, but in the end
provides too little when you really want it to be flexible. His example
of JavaScript in menu items is brilliant.

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

I've since thought a lot about these directives and I have a compromise
in mind. I need to find time to write it down... Let's stop discuss this
particular point right here and instead deal with it when the time comes.

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

If you want to do that, why not. I wouldn't like to see it in Zope 3
itself, though. And I wouldn't want to document it in my book. It's just
too hard.

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

I know what you're talking about. However, the merging of the lists will
unlikely affect this in a significant way (neither positively nor
negatively). Most topics are currently either cross-posted or they
should be cross-posted because they concern both target audiences. But
cross-posting is lame, hence the suggested merger.

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

Ok.

Philipp