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 Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com