Roger Ineichen wrote:
> Philipp von Weitershausen schrieb:
> 
>> Roger Ineichen wrote:
>>
>>> class LanguagesVocabulary(SimpleVocabulary):
>>>     """... languages from a translation domain."""
>>>
>>>     implements(ILanguagesVocabulary)
>>>
>>>     def __init__(self, context, domain='zope'):
>>>         terms = []
>>>
>>>         # collect languages from translation domain
>>>         trans_domain = getUtility(ILocalTranslationDomain, domain)
>>>         languages = trans_domain.getAvailableLanguages()
>>>
>>>         for lang in languages:
>>>             terms.append(SimpleTerm(lang, lang, lang))
>>>
>>>         terms.sort(lambda lhs, rhs: cmp(lhs.title, rhs.title))
>>>         super(LanguagesVocabulary, self).__init__(terms)
>>>
>>
>> You can, of course, leave this as it is and implement the 'tiks'
>> vocabulary as:
>>
>> def tiksLanguagesVocabulary(context):
>>     return LanguagesVocabulary(context, 'tiks')
>>
>> and then register that as a regular IVocabularyFactory utility, in case
>> you're keen on saving lines in Python or just hesitant to create classes.
> 
> I need to do this in python for each "language vocabulary".
> So we defently loose the ZCML as a compoent registration layer
> and need a additional layer called python for registering a component!

No, we don't. We lose ZCML as a component *creation* layer. Registration
is done by ZCML, and only registration.

> I think you didn't understand what this means?

I do. I gave examples. I changed the Zope 3 source. And, foremost, I
explained it in the proposal. I get the feeling *you* didn't understand
what I meant with the proposal.

> Are you realy think it's a better option to have a mix of python and
> ZCML for register components?

No. ZCML is about registering components. Python is about implementing
them. It's as simple as that.

>>> I could live with that, but I don't understand why I loose additional
>>> to this the reusablility and also the readability in ZCML?
>>
>>
>> I think
>>
>>   <utility component=".tiksLanguagesVocabulary" name="Tiks Languages" />
>>
>> reads quite well.
> 
> Why should I do this in ZCML if I have to do the first part of a
> configuration in python. There is realy no reason to define this
> in ZCML if I have to define the factory. It will become a YAGNY
> and developer start to do this:
> 
> def tiksLanguagesVocabulary(context):
>     return LanguagesVocabulary(context, 'tiks')
> 
> factory = tiksLanguagesVocabulary()
> provideUtility(factory, name="Tiks Languages")

I doubt that people will start doing this. Just as much as people don't do:

class FooBarAdapter(object):
    implements(IBar)
    adapts(IFoo)
    ...
provideAdapter(FooBarAdapter)

>>> Philipp can you tell me why this is better if we loose the concept for
>>> quick adding a new utility providing kws like the 'domain' attribute in
>>> example.
>>
>>
>> I explain this in the proposal:
>>
>>   "First, it is the only directive to take arbitrary arguments and by
>>   this it defies one of the initial aspects of ZCML (which is being
>>   restricted to a certain set of directives and parameters)."
> 
> 
> That's no true.

So I was mistaken about the "only" (I wasn't aware about
viewletManager). The rest of the statement is still true, namely that
arbitrary arguments are hard to grasp and explain.

> The <vieletManager> uses this pattern too.

Then I think we should rethink that approach as well.

> And the base pattern which makes it possible is well known in python.
> (args, kws). Do you also mean this isn't a good concept?

Indeed.

> I gree with you if you saying that arbitary arguments are to magic in ZCML.
> But another option then remove this is to document it. Isn't that the
> real problem? Is ZCML only to magic and hard do understand becaus of to
> less documentation and samples?

You can't solve all problems by documenting. No matter how many pages
you write about a certain thing, if it's too complicated, people will
never be able to use it intuitively.

I can use <utility /> very intuitively. Having to think about all those
other special directives makes me unproductive because I have to look up
all the time how they work. And in the end they just register a utility.

Ruby on Rails makes a great point: No XML situps. For some reason,
people *love* this point. In Zope 3, we deliberately decided to do XML
situps, but there are *a lot* of people who think we could do with a lot
less. Jeff Shell made a great point when he dissected
zope.formlib.namedtemplate:
http://article.gmane.org/gmane.comp.web.zope.zope3/17318.

In this post, Jeff also makes another great point: Creating things in
Python and doing only the registration in ZCML gives you far more
flexibility, apart from the fact that through the repititiveness of
intuitive directives you're actually more productive.

> (off Topic)
> I realy don't understand that people can understand and work with Plone
> and say that ZCML is to magic? But perhaps this is because Ploen is well
> documented and ZCML directives are not;-)

I consider APIDoc as well as the appendix to my book (which has
examples, btw) a rather good documentation of ZCML. But the appendix is
~100 pages thick. That's too much. Also, having to go to APIDoc or
opening my book every time you want to use a directive makes me
unproductive...

I don't understand your bashing Plone. If you want to add some substance
to your critique on Plone, be my guest, though this is hardly the place
for it.

>>> So this means if I need another LanguageVocabulary utility for a new
>>> domain, I have to write new factory, just for use another
>>> domain='foobar' attribute.
>>>
>>> Should we add the vocabulary directive to a higher level namespace
>>
>> What is a "higher level namespace"? Either way, I'd rather reduce the
>> amount of namespaces we have (perhaps to just the 'zope' one and
>> 'browser').
> 
> 
> Reduce the namespace is welcome. I vote for a single namespace called
> "zope" and merge the browser:view and zope:view to one.

That's a different discussion.

> But the problem is you removed a hole concept called vocabulary directive.
> 
> This concept contains:
> 
> - reduce lines of python code,
> 
> - Offers a understandable (informative) name in form a of a directive

This "informative" name becomes absolutely useless when you start
wondering how you actually find a vocabulary... The directive tells you
NOTHING about that. How on earth are you supposed to know that you have
to look up a utility for IVocabularyFactory???

> - Makes vocabularies resuable without write additional python code

If that's your goal and you really want to save lines of Python code
(which isn't my goal at all), then why don't you implement your own
"high-level" ZCML directive? Everyone is welcome to do so, though I
would highly discourage doing too much in ZCML.

> The big problem we have is, we have a different meaning what ZCML
> should be.

It seems so.

> I think ZCML supports registration and python supports
> everything except configuration.

I very much agree.

> I like a strict separation if possible.
> Now you are going in a direction where we mix both concept with each
> other.

On the contrary! Directives like <vocabulary /> mix implementation and
configuration because they both create and register. <utility />,
<adapter />, etc. just register. That's ZCML's primary job and my goal
is to reduce its functionality so that ZCML is more about registration,
not so much about creation.


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

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


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.

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

Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to