[Zope3-dev] What is ZCML?
What do you think about the following: We have three concept in Zope 3 which are the real base for Zope 3 as application server. This are: - python - Zope components - ZMCL Each of them are well separated. Python is well documented, Zope 3 is also good documented for a devleoper in it's REAMDE.txt files and unit tests. And ZCML is sometimes pure magic because of it's different intepretation what it should be. I'm a little worry about in what direction ZCML is going. Right now we have two options. This are: - ZCML as a registration layer. - ZCML as a configuration layer. What does this exactly mean? This are two targets of ZCML. Some developer think ZCML should only register python defined methods or classes and other think ZCML should configure components which probalbly will need to register classes driven from meta classes or similar thing. The first concept registration can fully be done in python. There is no need for doing it in ZCML. This way ZCML will become a optional concept which also could be replaced by doing directly in python. If we are going in this direction with ZCML I'm sure we don't reflect the component aspect of Zope3 as a Component Framework. The second concept configuration offers ZCML as a standalone concept and ensures that we only use ZCML as the glue for the components. In this concept is the main target to offer a way for reuse Zope3 components without to write additional python code. The API is well defined in different metaconfigure files and the relevant interfaces. I think both concept has their benefit and also are not the answer at all. Right now ZCML is going in the direction of a registration layer which will exclude the option to use ZCML as a configuration layer and register components without to write additional python code. This is bad. Remember the initial target of ZCML. ZCML means Zope Configuration Markup Language and was or is a concept which makes it possible to configure things. The real question now is what are things? Are things: - additional python classes or methods for configure components or - component iself I think the base layers where we use in Zope 3 as a application server are: python -- zope component -- ZCML And I also think: Zope components are easy to handle because the are only based on python and python offers the API which we understand. ZCML could also be so easy if we respect ZCML as a real fully fnctional layer. Which offers the API defined in the different metaconfigure files. But right now ZCML is going in a direction which requires to use Zope components and python as layers. This I think is a fundamental bad thing. We abstract python in Zopes components and additional we get nice interfaces which makes it easy to follow and understand. It could be so easy if we use ZCML as a layer for configure Zope 3 components without to touch the python layer. For me there is no reason strong enough that we should use the python layer for configuration and registration in ZCML. Some people think because it's easier for them to write additional python classes or methods and use the existing python knowlegde that this is enough reason to mix ZCML with python and Zope components. Is this really a good concept? I donp't think so. Propably in the beginning, but how can we handle the complexity when we mix everything with each other? If we go in the direction of ZCML as a registration layer, we have to change the model of our layers and we will get: - python - Zope components - Zope registration components - ZMCL What do you think about that? Are I'm totaly wrong? -- Regards 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
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: [snip] But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. I share these sentiments. Not that I have a particularly sick feeling (I've been immunized by too much exposure? :) but because I'm grasping for ways, patterns, to make my code look better, briefer, shorter, less repetition, more reuability. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. I definitely acknowledge his one. 2. Someone shows me how to avoid repetition in ZCML. Grasping around here myself. We need to show more people than just Shane and Martijn too - we need to be able to reach a wider audience if this is going to work. 3. We decide that ZCML is a failed experiment. On the one hand, I'm not willing to do that. On the other hand, if ZCML is to be a simple registration language, I am starting to idly wonder why a bunch of CSV tables wouldn't do (and might not be clearer and simpler). If ZCML is to be a simple registration language, I'd also like there to be a 1 to 1 mapping of ZCML statement to Python code. Right now there is a mapping and while it may be reasonably straightforward, I personally am still lost in APIs (and it looks like Jeff Shell is too). This learning curve should be smaller. Whatever we do, if ZCML is to be replaced we need to replace it with something. I think many of the notions of ZCML are dead on - this registration shouldn't be happening in normal Python code mixed with the rest but as a separate activity. It should allow overriding. It should be amenable to analysis. 4. We decide that ZCML should gain more qualities of a high level language. I personally am quite interested in exploring this, but I'd like to see some examples of what this would actually look like, concretely. 5. We solve this some other way. This would be satisfactory too. :) I recognize that #3 and #4 are very risky, and we've already been over the risks, but I include them because they still feel better than the status quo. We can mitigate some of the risks of both #3 and #4 as we could do them as separate, experimental, non-Zope projects. I can't help but wonder if ZCML is largely a reaction to the horrible initialize(context) methods in CMF products. In non-CMF Silva we also got horrible initialize(context) methods, and we've got horrible and long install.py files. When looking at ZCML we should clearly keep in mind that what it replaces. Silva's install.py expressed in ZCML would be preferrable to what we have now in most ways. Those beasts are horrible because they are based on workarounds of workarounds. The workarounds came about because we were more willing to add code than fix code. That attitude prevailed because we didn't have automated tests of Zope. And because we weren't as good at designing good Pythonic APIs as we are now. At least I've definitely gotten better at that over the last years. Now that we have automated tests, programmers are more likely to fix code rather than add code, so we can expect to see very few workarounds, so initialize(context) garbage won't happen. I'm not convinced of this, myself. If Zope 3 becomes popular, lots of application developers won't be using automated tests in Zope 3 code either. In addition, you get unnecessary workarounds because people fail to see the right way to do it and are in a hurry. I feel that a declarative and domain specific language can help in such cases. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Shane Hathaway wrote: [snip] But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. I share these sentiments. Not that I have a particularly sick feeling (I've been immunized by too much exposure? :) but because I'm grasping for ways, patterns, to make my code look better, briefer, shorter, less repetition, more reuability. Reuse is overrated. :) Honestly, I think reuse best happens in Python. I've found it easy to wrap and roll things up into more common APIs for personal use. This has been one of the really positive things of Zope 3. But for that sort of roll up to happen, the environment needs to support common refactoring patterns (extract method/class/etc). I do not believe that ZCML supports that. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. I definitely acknowledge his one. 2. Someone shows me how to avoid repetition in ZCML. Use less ZCML. Be creative. Have fun. This answer doesn't work for everybody, and isn't as easily applicable as I would like. 3. We decide that ZCML is a failed experiment. On the one hand, I'm not willing to do that. On the other hand, if ZCML is to be a simple registration language, I am starting to idly wonder why a bunch of CSV tables wouldn't do (and might not be clearer and simpler). Because editing CSV tables sucks an even bigger electrical outlet. (Honestly - I'm too stupid to understand Excel... But maybe I'm saying that after spending a week writing an CSV inventory importer. Ugh). If ZCML is to be a simple registration language, I'd also like there to be a 1 to 1 mapping of ZCML statement to Python code. Right now there is a mapping and while it may be reasonably straightforward, I personally am still lost in APIs (and it looks like Jeff Shell is too). This learning curve should be smaller. I agree. I think Jim said early on that ZCML should be theoretically replaceable. Looking at many of the directive implementations, I do not see this. If the Zope 3 CA vision that I had is to have a good chance of succeeding outside of this community, I'd hope that it doesn't ship with or require ZCML. Whatever we do, if ZCML is to be replaced we need to replace it with something. I think many of the notions of ZCML are dead on - this registration shouldn't be happening in normal Python code mixed with the rest but as a separate activity. It should allow overriding. It should be amenable to analysis. I'm mixed about whether this should happen in normal Python code. A few months ago I laid out a vision for how I think it would work. Basically, configuration would have to be a very locked-down module: it couldn't really be imported by regular code, wouldn't really execute when called from 'regular' code. It would, in short, try to somehow enforce the importing a package should NOT automatically register its components. 4. We decide that ZCML should gain more qualities of a high level language. I personally am quite interested in exploring this, but I'd like to see some examples of what this would actually look like, concretely. We have a high level language. It's Python. I think that people just have gotten bad at thinking in objects and usable APIs and have somehow developed a strange fear of the language. I don't get it. class ArticleEditForm(form.EditForm): form_fields = fields.FormFields(IArticle, ITaggable) form_fields['tags'].custom_widget = ... Wow. So much better than browser:editform. It's possible to design other parts of the system like this. I just know it is. like this? yes what is this? respects the Python developer. Now I know forms are a special case, as Tres or Shane or both brought up. I was just impressed by the amount of actually-helpful objects, APIs, and base classes in formlib. That one package has made me more productive and flexible than most of the rest of Zope 3's default elements (zope.interface/component/schema/app.container excepted). I think we can learn something from it. At least, I hope we can. Zope can, at the end of the day, only provide some good core tools. I think those tools, and the concepts behind them, should be simple. Then if someone wants to build the giga-framework on top of it, they can. But also, if I'm writing what should be a simple application like the PyWebOff example, I don't have to waste time on countless elements that don't apply. I don't have to waste time editing more XML than Python. Etc. Honestly: Rails is very appealing with its we use Ruby for everything message. But Ruby's syntax and use of blocks seems to make this more tenable than it is in Python. I'm not a big fan of their convention over configuration design, but it's winning me over slowly. The more I fight
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Martijn Faassen wrote: [snip] I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. Agreed. That's why magic in software has a bad reputation. But it's not bad if it works almost invisibly. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. I suspect we're in a state of violent agreement here. :) What you say about this in part depends on who you're talking to. Repetition of code is generally bad. Many programmers don't abstract *enough* and copy paste code all over the place. We don't want to make them more wary of automation. To go to a related but slightly different topic: One form of abstraction I'm still grasping for in Zope 3 is support for coarse-grained components. When I have a whole bunch of (local) utilities, content objects, views, permissions and the like that work together, tied together with quite a bit of ZCML, I'd like to be able to reuse that more easily in an application. Right now the only way to reuse code like that I can find is to copy it and modify it, but that's wrong - it'd like to be able to use all that code from my application without having to copy or modify it. For instance, for an application I needed a user and group management system with a ZODB user interface. This uses the catalog, defines a number of content objects and adds a bunch of views. Extracting this functionality from the application turned out harder than I'd like it to be. And then I haven't figured out yet how to reuse it without having to copy and modify code... Are there patterns to do this in current Zope 3? Part of the problem is a dependency on local utilities - I believe the new local utility registration API you're working on should help there. For the rest, I guess I could just copy and rewire the ZCML, but that is quite a bit of work and failure-prone. I could also invent a ZCML statement with a much higher level of abstraction that takes the place of dozens of lower level statements, but people argue against this rather a lot. What other strategies could I employ? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Lennart Regebro [EMAIL PROTECTED] wrote: OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? None, evidently. So it was a bad brainwave then. :) Ah well. Beware the Ideas of March, as my grandad never said. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: ... I suspect we're in a state of violent agreement here. :) Then why do people have to argue every single point ad nauseum? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Martijn Faassen wrote: ... I suspect we're in a state of violent agreement here. :) Then why do people have to argue every single point ad nauseum? Because we want to understand the current decisions and thinking. I never intend to argue, but email is such a poor discussion medium that the words often come out sounding like an argument. The statement explicit is better than implicit, except when it's not is void of any meaning. I think I know what it means, but I can only guess what you think it means. I attempted to elaborate so you can confirm or deny a common understanding. I don't think I elaborated enough, though. It seems to be a fundamental principle for building Zope 3, so we all need to understand it the same way. Back on topic, the message I'm hearing about ZCML is confusing: high level configuration is good, but ZCML isn't going to handle it because we want to limit the number of directives. Does that mean we're going to use Python code to generate ZCML? (That's a rhetorical question... I think.) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: ... Back on topic, the message I'm hearing about ZCML is confusing: That's because we don't all agree. high level configuration is good, but ZCML isn't going to handle it because we want to limit the number of directives. Does that mean we're going to use Python code to generate ZCML? (That's a rhetorical question... I think.) What I've said is that ZCML should be about configuration, especially registration, and *not* about defining things. I've said things should be defined in Python and registered in ZCML. I don't necessarily have a problem with high-level configuration directives that configure several things at once, although I'm wary that the benefit would be worth the obscurity. I'd also like to acknowledge Tres' point about high-level non-Python definition mechanisms for things like forms and schemas. I agree with him that such facilities could be a good thing. I may disagree with him on whether these should be ZCML. I definately don't think that they should be. Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: I'd also like to acknowledge Tres' point about high-level non-Python definition mechanisms for things like forms and schemas. I agree with him that such facilities could be a good thing. I may disagree with him on whether these should be ZCML. I definately don't think that they should be. it depends a lot on the availability of softwares and of standards used to create such definitions. Julien has done some work on using XML schemas in zope3 as you know: http://blogs.nuxeo.com/sections/blogs/julien_anguenot/2005_08_19_xml-schema-support-on http://svn.nuxeo.org/trac/pub/browser/z3lab/zope/xmlschema/trunk/demo/ XForms could be a good choice for defining forms too. I'm using JSON for MVC definitions, because they can be used in Javacript without much fuss. YAML seems to be easy to read too, etc. SVG can be investigated too for defining layouts, graphical objects etc. this is really an area where one should look to see what already exists. sorry if I'm off-topic. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. 2. Someone shows me how to avoid repetition in ZCML. 3. We decide that ZCML is a failed experiment. 4. We decide that ZCML should gain more qualities of a high level language. 5. We solve this some other way. I recognize that #3 and #4 are very risky, and we've already been over the risks, but I include them because they still feel better than the status quo. I can't help but wonder if ZCML is largely a reaction to the horrible initialize(context) methods in CMF products. Those beasts are horrible because they are based on workarounds of workarounds. The workarounds came about because we were more willing to add code than fix code. That attitude prevailed because we didn't have automated tests of Zope. Now that we have automated tests, programmers are more likely to fix code rather than add code, so we can expect to see very few workarounds, so initialize(context) garbage won't happen. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Lennart Regebro wrote at 2006-3-14 21:17 +0100: On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote at 2006-3-15 07:29 -0500: ... Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. Neither costs nor benefits are objective but subjective. For me, when I repeat the same sequence for about half a dozen of times, I am crying out for an abstraction (if possible with a well chosen name) that gets rid of the repetition. I am rarely interested in details and am happy when lots of them are hidden -- that's no cost but benefit. Well chosen names give me enough feeling about the overall effect that I rarely need to dig into the details. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. Could you give a more specific example? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. Could you give a more specific example? My attempt to solve the PyWebOff challenge, which I posted here: http://mail.zope.org/pipermail/zope3-users/2006-March/002608.html The ZCML I wrote in that message is quite representative of the ZCML I wrote for a Zope 3-based system that's now in production. (The system is a management interface for a Beowulf-style microfilm scanning cluster.) The repetition isn't a showstopper, obviously, but it makes me feel bad, so Zope 3 ends up being no fun. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/15/06, Dieter Maurer [EMAIL PROTECTED] wrote: I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) I think that amongst web app frameworks we are. I don't know of any other aspect oriented ones. I could be wrong. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] as configuration in Python code is more flexible and packages can form a more self-contained whole. Wrong! This is an important point. No one in the know is proposing using Python for configuration. Python is for definition, not configuration. The problem with some of the high-level ZCML directives is that they performed *definition* in addition to configuration. For example, browser:page creates new classes. It's important that definition be done in Python. Configuration should be done in ZCML. Okay, since I'm wrong, I think it would be useful if you spelled out the difference between definition and configuration. Admittedly, the distinction is not always crisp. Similarly, the difference between low-level configuration for programmers and high-level configuration for adminstrators is not always crisp. The philosophy is important though. ZCML is configuration, not definition. Generally, Python is for definition, although, sometimes other languages are used too. Obviously, template languages are used for definition too. Tres has argued that declarative languages might be better for defining interfaces. Also, XMI is an interesting case, as it, potentially, fills both roles. :) I have some intuitions but it's obviously not fully clear to me, and I suspect others may also have difficulty. I'll phrase give examples of things that I could interpret as configuration or as definition. Which of the following is definition and which is configuration (or something else entirely?): * Specifying which pages can be viewed for an object providing a particular interface. Low-level configuration * Attaching annotations to objects of a particular interface. Saying that we want to use a particular adapter is configuration. Implementing that adapter is definition. * Attaching menu entries to objects of a particular interface. Low-level configuration. Defining the menu entries is definition. * Setting the layer a view is in. Low-level configuration. * Specifying which page template is used to render a particular view. Low-level configuration * Setting the permissions needed to access the attributes of an object. Low-level configuration * Setting up the indexes in a catalog. definition * Setting up a catalog for a site. Creating the catalog is definition, registering it is configuration * Determine what is shown in which columns are shown in a table on a web page. Definition * The initial sorting order of these columns. Grey :) * The batch size of a particular batched view. Grey * Which resources should be included in a web page displaying a certain widget. I don't know what this means. * The relational database we've connected our application to. High-level configuration * The mailserver we've connected our application to. High-level configuration * The fields that show up in a form. Definition * Setting up which fields that show up in a form are required. Definition * Setting up which file extensions we want to allow to be uploaded into a file upload widget. Grey. I would expect that you might also want to define handlers for these. So you'd define the handlers and configure their use. Perhaps these questions are too high level and should be split up into multiple questions. What criteria do you use to determine whether something is definition or configuration? It's hard to say without repeating the words or synonyms. :) If it's I also suspect that some of these are local or application specific configuration. It makes sense to store some configuration in the ZODB, and thus, at present, not express it in ZCML at all. Yes. What is configuration sometimes depends on the application in question. Yup Should there be high-level directives in ZCML? I don't think they should be disallowed, but you really have to ask yourself if the automation they provide is worth the extra burden of understanding what they do. The other drawback of using ZCML for automation is that complicated automation is often quite cumbersome to express in ZCML. Another drawback is that such automation often combines various bits of python code with ZCML and you have to look at multiple files instead of just one. Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. Anyway, the main thrust of the ZCML simplification is to use it just for low-level configuration, not for definition. So to make it clear, you're in favor of ZCML interpretation #2, with the modification that Python code should not be
Re: [Zope3-dev] what is ZCML?
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. . Anyway these are the ones that should be moved out of ZCML I guess since they are so site or application specific that it is difficult to be reuse them as components in other setups. But after rereading your mail it seems that this is what you said in it. simply put, high-level ZCML would be for me being able to associate a collection of resources to a given skin in a global way, or saying that a given LDAP directory should be plugged into a given authentication service, but without specifying LDAP port, servers, when doing the connection (because I have an object in ZCML that stands for the LDAP directory and another one that refers to the authentication service) /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. Wrong. the page directive defines a class and combines multiple configurations. This is definately a higher level of abstraction. . Anyway these are the ones that should be moved out of ZCML I guess since they are so site or application specific that it is difficult to be reuse them as components in other setups. Well, no. They are not application specific. Rather, we feel, after getting experience with them, that the benefits they provide don't justify the hiding they do of what's really going on. The same could have been true if they were written in Python. In fact, we have a similar problem with some of our Python menu APIs, which automate too much and actually obscure what is really a simple pattern. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Roger Ineichen wrote at 2006-3-13 21:57 +0100: ... I think ZCML is defently not configuration in the clasic understanding of configuration. Defining directives in ZCML means we bind components together to a application. If developer share this configuration layer with admins and use it for tasks like configuring a mail queue (like we do right now) I'm sure we will get a big mess for admins and developers understanding of what ZCML should be. Why do we need ZCML for this? It can be done with Python equally well... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Sidnei da Silva wrote at 2006-3-13 20:21 -0300: ... That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. As I understand, no other framework out there gives you this. Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote at 2006-3-14 07:23 -0500: ... * Setting up the indexes in a catalog. definition Really? I would consider it configuration -- even high level configuration. ... BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Lennart Regebro wrote at 2006-3-14 09:19 +0100: On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. Right you are, you don't even need to subclass it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Jean-Marc Orliaguet wrote: I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. Wrong. the page directive defines a class and combines multiple configurations. This is definately a higher level of abstraction. OK, but that's not violent abstraction. For a python programming, going to ZCML does feel like wow, I can do some high-level configuration of my application, we are still configuring fairly low-level components (pages, menus, views ...), they still need to be configured on a higher level for the application to start working. The effort is not necessarily justified compared with how views for instance are declared inline with the code. By looking at zope/app/publisher/browser/viewmeta.py it is clear that most of the code is there handle all the different page registration options (templates, attributes, security, ..). the fact that the abstraction done in ZCML does not succeed in hiding information is an issue, IMO this is because the directives in ZCML correspond to low-level objects and the objects' internal way of functioning is getting too much exposed (not enough encapsulation) as its the case with browser:page. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Dieter Maurer wrote: Jim Fulton wrote at 2006-3-14 07:23 -0500: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. To say something is bad only because it's implicit or abstract is a poor argument, but to say something is bad because it's a leaky abstraction is an argument that can be explored further. For example, it's not very sensible to say implicit acquisition is bad because it's implicit, but it is quite sensible to say it's bad because it leaks all attributes and forces a lot of code to be aware of wrappers. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: Dieter Maurer wrote: Jim Fulton wrote at 2006-3-14 07:23 -0500: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. To say something is bad only because it's implicit or abstract is a poor argument, but to say something is bad because it's a leaky abstraction is an argument that can be explored further. That's not what I was refering to. For example, it's not very sensible to say implicit acquisition is bad because it's implicit, but it is quite sensible to say it's bad because it leaks all attributes and forces a lot of code to be aware of wrappers. All abstractions have their dark side. Things can have strengths and weaknesses. I stand by my argument that indirection and abstraction are bad. Of course, they are often also good. They should be used when the good significantly outweighs the bad. Too often though, people don't realize that indirection and abstraction have an inherent cost and use them when the benefit doesn't outweigh the cost. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. which is strictly equivalent to Implicit is better than explicit, except when it's not. :-) and when it's not ... explicit is better. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Tuesday 14 March 2006 16:44, Jim Fulton wrote: I stand by my argument that indirection and abstraction are bad. Of course, they are often also good. They should be used when the good significantly outweighs the bad. Too often though, people don't realize that indirection and abstraction have an inherent cost and use them when the benefit doesn't outweigh the cost. He he. :-) Was this a Jim brain teaser? :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Zachery Bir wrote: On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote: which is strictly equivalent to Implicit is better than explicit, except when it's not. :-) and when it's not ... explicit is better. Clearly arbitraritude is better than claritization, except when it is. Or maybe: a desire to argue pedantics is better than a desire to write code (and configuration wink). Zac yes, there is a lot of truth in what you wrote, and the opposite too.. maybe the zope philosophical findings should be published in a book :-) /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] what is ZCML?
Hi there, In this mail I'd like to make explicit some competing design influences on ZCML. The first interpretation of what ZCML is: ZCML is a configuration language that provides abstract directives for configuring Zope applications. If we're setting up a page, we use the page directive. If we're setting up a skin, we use a skin directive. If we're setting up an adapter, we use an adapter directive. Even if two directives underneath only set up adapters (such as browser:page and zope:adapter), we still think it's valuable to have two directives, as we make explicit what we are doing. ZCML should be readable without having to consult Python code a lot. I.e. if we set up an adapter, we know what interface it's working for and we know what interface the adapter is providing just by looking at the ZCML. I believe that the first interpretation is the traditional interpretation of ZCML. A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. (the third interpretation of ZCML is that it's evil and should be destroyed I'd like to leave out of this discussion - the outcome doesn't matter that much if you're of that persuasion) Of course, these interpretations have never been made very explicit. We have discussions where they are implicitly present, though. Reducing the namespaces in ZCML drastically makes more sense from the second perspective than from the first. Adding a new ZCML directive to support annotations makes more sense from the first and doesn't make much sense from the second interpretation. Which one of these interpretations is the right one for the future? I realize that the interpretations I sketch out may be extreme ends of a spectrum. I haven't seen a lot of advocacy the removal of browser:page, for instance. It may be that the real ZCML should be in the middle of these two interpretations. If so we should make our criteria explicit somehow, too - when do we really want to add a directive, and when do we really not want to remove a directive? Perhaps there is whole other perspective possible on ZCML that resolves this whole issue. Let us know if you have one! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer [EMAIL PROTECTED] wrote: Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). I tend to agree. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. IOW, most of the directives we need have already been invented. [1] We don't want to build high level directives; ZCML will follow the BASIC school of language design. :-) [1] http://www.inventionmysteries.com/article4.html While I was initially on board with the idea of reducing the number of directives, I've changed my mind. I think we want high level directives and we want people to feel free to write new directive types. We want tools that let us inspect and search the resulting low level directives. If we have to use ZCML, then ZCML should be expressive. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Alec Mitchell [EMAIL PROTECTED] wrote: On Monday 13 March 2006 10:59, Dieter Maurer wrote: Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). +1 The first time I saw: adapter factory=.MyFactory / I was a bit disturbed. What's the point? It tells you nothing unless you refer to the actual implementation. Why not just put the registration in python alongside the implementation if that's where the configuration of provided and required interfaces is going to be? I had considered one of zcml configuration's greatest benefits was that it could give a high level overview of how pieces of a package were interconnected. Of course it's still possbile to do things the old way, but I get the impression that it's discouraged. Brevity is not always a boon, though that cuts both ways here (adding a new magical seeming zcml declaration to save a copy/paste here and there may not be the best idea either). I consider one of ZCML configurations greatest detriments is that it does many things that cannot be easily replicated in Python (one day, you'll probably come across having to set up just the right unit test harness and you'll realize what I mean). I consider one of it's greatest detriments is that it completely destroys Don't-Repeat-Yourself. You can do: adapter factory=.MyFrank provides=.interfaces.IFrank for=.interfaces.IBun .interfaces.IRelish / class MyFrank(object): def __init__(self, context): # ... See? No declarations on MyFrank that says what it does. Or you can do: class MyFrank(object): implements(IFrank) adapts(IBun, IRelish) def __init__(self, context): # ... And do the full adapter line in ZCML. But then you've just said the implements / adapts twice. Using different words, I should point out. Or you can do the adapter line the short way and let the Python code say what it does. Three options. I know I'm not consistent with the ones that I choose. I just know that I spend more time looking at Python code and I'd rather understand what the Python code is doing by looking at the Python code. Three options. That sure kills the there should be one, and only one, obvious way to do it theory too. Don't even get me started about when I might want to use 'zope:view', 'browser:view', or just plain old 'adapter' (since a view is just a multi adapter, as are content providers and viewlets and all sorts of other fun and useful combinations). Anyways - for me, the point of adapter factory=.MyFactory is that I already said in MyFactory that it implements and adapts certain interfaces already. I don't want to say that twice. And I think it's very important for the Python code to say what it does, so when I come back to a module five months later I'm not staring at MyFactory going yeah, but what is it? And I also think it's important for code to be debuggable, inspectable, so that when there's a bug from ... well, wherever it came from, code can be traced. It's very hard to trace through ZCML statements, and what they've produced. From dynamically made classes to the weirdness of the metaconfigure.py code (handlers, discriminators, etc) - all of those things get in the way of a productive pdb or why is this thing blowing up? session real fast. In my experience anyways. So I figure - the less ZCML I use, the better it will be for me to maintain in the future. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Monday 13 March 2006 10:59, Dieter Maurer wrote: Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). +1 The first time I saw: adapter factory=.MyFactory / I was a bit disturbed. What's the point? It tells you nothing unless you refer to the actual implementation. Why not just put the registration in python alongside the implementation if that's where the configuration of provided and required interfaces is going to be? I had considered one of zcml configuration's greatest benefits was that it could give a high level overview of how pieces of a package were interconnected. Of course it's still possbile to do things the old way, but I get the impression that it's discouraged. Brevity is not always a boon, though that cuts both ways here (adding a new magical seeming zcml declaration to save a copy/paste here and there may not be the best idea either). Alec ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer [EMAIL PROTECTED] wrote: Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). I think differently. ZCML is primarily for programmers. ZConfig style configuration is what administrators deal with more, isn't it? Maybe ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. I don't think of ZCML as administrative configuration. I'd rather have Python files that I can read and understand what's going on without having to consult ZCML files, directives, documentation, and so on, just to understand why a certain class whose code I'm looking at is getting its behavior when I can see no superclass. I'd like to know that a class I'm looking at is an adapter and what it provides and what it adapts without having to dig through a large ZCML file. An administrator is not likely to override my 'inplace_editor' view. He may want to configure global services (if my application is written that way) such as RDB connection parameters and mail services. But beyond that, just loading it up in package-includes or in a specific file is likely to be the bulk of 'administrative' effort. Did administrators go into your ``initialize(context)`` functions in your Zope 2 Product's __init__.py files and change things? That's what I view ZCML as being - a better version of that. (Better in only that configuration and initialization can be executed separately from Python imports) -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Shane Hathaway [EMAIL PROTECTED] wrote: Martijn Faassen wrote: A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. IOW, most of the directives we need have already been invented. [1] We don't want to build high level directives; ZCML will follow the BASIC school of language design. :-) [1] http://www.inventionmysteries.com/article4.html While I was initially on board with the idea of reducing the number of directives, I've changed my mind. I think we want high level directives and we want people to feel free to write new directive types. We want tools that let us inspect and search the resulting low level directives. If we have to use ZCML, then ZCML should be expressive. Then why do we have Python? Is Zope going to be a write ZCML directives to write your Zope app system? Or is it going to be write Python code to write your Zope app system? I don't know if it's possible to use a ZCML configuration-execution outside of ZCML, which makes testing an awful hard beast sometimes. There's functionality that's locked away inside the directives that you then have to have not only the Zope environment set up to run, but a ZCML environment too. Pain pain pain pain pain. Unlock the magic. If it must exist, make it available and understandable to me. Don't hide it under more layers and verbs and nouns that conflict and change meaning depending on if you're using ZCML and Python. Make ZCML More Expressive - did we learn nothing from DTML Expressions? It starts out simply enough, but how long until we have more and more logic in ZCML? We already have this conditional that I barely understand (but appreciate in theory). Why design a language at all? I only want ZCML to allow me not to take on a packages provided components when I import it. I don't want to start thinking I can write an enterprise workflow and document management system in it. Let Python be the language. Let ZCML exist to do the final step of loading/registering registerable objects in a predictable manner, and to provide the few things that we don't want to pollute our (or others) Python code with, like security declarations. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote: | And I think it's | very important for the Python code to say what it does, so when I come | back to a module five months later I'm not staring at MyFactory going | yeah, but what is it? One thing that must not pass by unnoticed is that one of the points of 'Why ZCML' is that it allows you to 'do stuff' (configuration?) with plain python code that wasn't written for, nor depends on, Zope 3 directly. That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. As I understand, no other framework out there gives you this. -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Sidnei da Silva wrote: On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote: | And I think it's | very important for the Python code to say what it does, so when I come | back to a module five months later I'm not staring at MyFactory going | yeah, but what is it? One thing that must not pass by unnoticed is that one of the points of 'Why ZCML' is that it allows you to 'do stuff' (configuration?) with plain python code that wasn't written for, nor depends on, Zope 3 directly. That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. As I understand, no other framework out there gives you this. I would suggest that is a component architecture feature, not a ZCML feature. If Zope were a hardware device, the CA would be the wiring and ZCML would be the schematic diagram. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Right. Everything else should be done in Python code, Sort of. as configuration in Python code is more flexible and packages can form a more self-contained whole. Wrong! This is an important point. No one in the know is proposing using Python for configuration. Python is for definition, not configuration. The problem with some of the high-level ZCML directives is that they performed *definition* in addition to configuration. For example, browser:page creates new classes. It's important that definition be done in Python. Configuration should be done in ZCML. Should there be high-level directives in ZCML? I don't think they should be disallowed, but you really have to ask yourself if the automation they provide is worth the extra burden of understanding what they do. Anyway, the main thrust of the ZCML simplification is to use it just for low-level configuration, not for definition. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Dieter Maurer wrote: ... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). As Jeffrey pointed out (and as I mentioned in my recent proposal), ZCML provides low-level configuration. It is aimed at developers, not adminstrators. Adminsitrators will use high-level configuration languages like ZConfig or ConfigParser. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote: You're aware of the DRY principle, right? ZCML is repetitive, and repetitive is wrong. We tend to think that repetition is *always* wrong, but in other fields there are cases in which it depends who the reader is, and how the repetition is expressed. One thing I learned in my long-ago days as a music student is that the least repetetive way to write a score is often the most difficult to sight-read. The stupidest, most repetitive way to write the score is very easy to read; it's completely linear, so the reader can't get lost. You can notate repetition easily enough, and make the score more compact, at the expense of requiring the reader to mentally construct the linear model and maintain more mental state while playing. I have no idea whether any of that applies to ZCML, so I'll re-lurk now. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Mon, Mar 13, 2006 at 04:40:09PM -0700, Shane Hathaway wrote: | I would suggest that is a component architecture feature, not a ZCML | feature. If Zope were a hardware device, the CA would be the wiring and | ZCML would be the schematic diagram. Great point! -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
