[Zope3-dev] Re: Vocabulary the next proposal
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 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. 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). 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'). or should we add it back to where it was. This proposal had been around for quite some time. Writing, reviewing and implementing it took quite an amount of my spare time. Note the option to go the new (simply but not reusable pure python) way is there in both concept. Not sure what you mean by this. And, what should we do with the factory and implement sub class directive before they get (re)moved? Huh? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Vocabulary the next proposal
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! I think you didn't understand what this means? Are you realy think it's a better option to have a mix of python and ZCML for register components? 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'm not sure what do you think. Do you think it's a way we should go or not? I think that's defently no way to go. 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, The vieletManager uses this pattern too. 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? 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? (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;-) 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. 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 - Makes vocabularies resuable without write additional python code The big problem we have is, we have a different meaning what ZCML should be. I think ZCML supports registration and python supports everything except configuration. I like a strict separation if possible. Now you are going in a direction where we mix both concept with each other. Which will end in a chaos and is not easy to support. Let me explain this a little more. The following pyhton class defines the vocabulary: class LanguagesVocabulary(SimpleVocabulary): ... languages from a translation domain. implements(ILanguagesVocabulary) def __init__(self, context, domain='zope'): terms = [] 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) And now we have(had) two ways doing the configuration: pure ZCML: vocabulary name=Tiks Languages factory=.tiksLanguagesVocabulary domain=tiks / then new concept requires a mix from
[Zope3-dev] Re: Vocabulary the next proposal
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
[Zope3-dev] Re: Vocabulary the next proposal
On Mar 25, 2006, at 5:41 AM, Philipp von Weitershausen wrote: 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. You then need to do a directlyProvides(tiksLanguagesVocabulary, IVocabularyFactory) on the function so that the utility zcml doesn't complain. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Vocabulary the next proposal
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
[Zope3-dev] Re: Vocabulary the next proposal
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
[Zope3-dev] Re: Vocabulary the next proposal
Philipp von Weitershausen schrieb: [...] 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. Yup, this means ZCML should do more and better. I'm just kidding ;-) [...] 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. Ok, agreed Philipp -- Mit freundlichem Gruss Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
