Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Jeff Shell wrote: [snip lots of good stuff about configuration in python code and its drawbacks] But if that were a route one decided to use, one would have to lay down VERY strict rules. Otherwise we lose all the benefits of the Component Architecture and start heading back into a free-for-all mess. I just wanted to indicate, belatedly as I just found this discussion, my strong agreement. If configuration moves into Python code, it should be under very strict supervision indeed. [snip lots more good stuff] . I think that the ZCML situation could be improved with: * simpler use - let Python code say what it adapts and implements. Let Python code subclass from BrowserView. Use ZCML to just register and name the object. Promote this in documentation, advocacy articles, and so on. * alternate syntax? Not Python, but maybe something python-ish but geared towards entering the kind of data references that one has to type a lot in configuration. * cut down on the magics like dynamic class creation. this was a frustrating surprise when I first encountered it a couple of months ago. * for many of the core ZCML configuration directives, explain their Python alternative. Not to promote its use when writing large systems, shared toolkits or frameworks, but to show how to test or just to use adapters and utilities in small applications that don't require the full Zope toolkit. And all of these are a good idea for exploration. Regards, Martijn ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Alen Stanisic wrote: On Fri, 2005-12-23 at 11:25 -0500, Stephan Richter wrote: [...] ZCML is a great way of getting a quick overview on how things hang together. I agree, I found ZCML very useful when trying to learn how Zope3 components work. Oh humbug. Every time I've wanted to find something in Zope 3 I've had to search dozens of ZCML files by hand. It's strange that no one else has had the same experience. Apparently I'm nothing like the rest of you smarties. ;-) Shane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On 12/23/05, Shane Hathaway [EMAIL PROTECTED] wrote: Jeff Shell wrote: I just believe - heavily - after many of my Zope 2 experiences that configuration as done by ZCML should be as separate from the code itself as possible. If it's going to be in the same programming language, it needs to be made clear what it is, what can be done, and what can NOT be done. Ok, but you broke your own rule. Quoting your blog entry [1]: zope.component.provideUtility(greyhounds, name='greyhound') [1] http://griddlenoise.blogspot.com/2005/12/zope-component-architecture-interfaces.html This code appears at module scope. You've hardcoded the configuration of a utility. You did it again with some provideAdapter() calls. You're doing configuration the same way Zope 2 does it. You created nontrivial side effects that no one can control without changing your code. Even worse, this is a public example which I myself promoted! I apparently made a mistake. Upon reflection, I realize that your example is dangerous and illegal, since it integrates poorly with Zope. You're outright wrong and your blog should be shot! I was not writing a Zope 3 Application Server Application - I had one utility and three adapters crammed into a make believe module :). In the second article, I moved those into 'basicConfigure()' functions anyways. My code used nothing more than zope.component and zope.interface, and that's all that I was trying to show. I do believe that the component architecture is and should be usable without ZCML. But I also believe that large systems such as the full app server and applications built on the larger Zope framework can benefit from it. Ok, not really. ;-) But this illustrates why the line between code and configuration shouldn't be a brick wall. Your example would have been much cleaner if you had written a function at module scope where you perform all registrations for the module. Then users of your module could choose to call your registrations or not. ... which is pretty much what you did in a later example, in basicConfigure()! [2] Users can choose to call basicConfigure(), and if they don't, they start with a squeaky clean configuration. See, this idea is not really mine. *You* configured things in Python code. You did it because it's natural and easier to explain. I'm suggesting a way to let you write configuration code safely, so that those who follow your example don't descend into a Zope 2 mess. [2] http://griddlenoise.blogspot.com/2005/12/zope-component-architecture-one-way-to.html I was also writing an advocacy post (in the first one) at midnight that was bordering days that nearly dropped me dead from the point of exhaustion. I wasn't wanting to show endless black magic - and then I wave my hands and everything is configured!. I was wanting to show how two modules - zope.component and zope.interface - could be used without the rest of Zope (aside from zope.exception, I believe). Not long after ZCML came into existence, I invented a way to configure using Python code, and I think I posted some examples. I realize now that the simple way I did it was wrong. What I'm suggesting now is to retain the semantics of ZCML but switch the syntax. It would be possible to automate the conversion of all existing ZCML files. The XML implementation of Zope configuration is an overreaction to the things that went wrong in Zope 2. Configuration in Zope 2 was bad simply because there was no consistent method of configuring things. Now that we have a fairly complete configuration system and a set of conventions, sloppy configuration will no longer proliferate in the Zope community, unless the system is too rigid. Your example broke convention, with potentially harmful consequences for people who follow your example, suggesting the system is currently too rigid. My example, again, was a single standalone module written on near zero sleep. It was by the second example that it had already grown to be too big to be configured in-line. I think you could achieve this with Python, but you'd need do document the hell out of it and put in a smart and restrictive system that would ensure that sloppy configuration didn't happen, that the 'configure.py' module was unused by anything but the configuration system, and that the package it was in could be loaded as a Python package/module without the 'configure.py' module (which would have the most requirements on the configuration of the outside system) be ignored or otherwise not blow up when trying to register against something not defined. Restrictions aren't necessary. If developers are simply told what the convention is and why they should follow it, they'll follow it. Again, the problem in Zope 2 was that there was no convention for configuration, so everyone made one up. Restrictions help. Or, at the very least, warnings. warning: configuration module imported by
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On Thursday 22 December 2005 18:48, Jeff Shell wrote: Other problems that I've had with Python based configuration in the past has involved not knowing when to do the configuration. Do I want to register the class I just defined in the module code? class Foo(...): pass registerAsFooable(Foo) Right, this is what twisted does and it makes it very hard to see what components are available and where they come from. It also makes it practically impossible to override components without getting into the ordering mess you mentioned. I also note that the code browser now supports looking at ZCML files. Not only will it highlight the code for you, but also provide links to specified components. I think this might be very helpful for people to discover the system. ZCML is a great way of getting a quick overview on how things hang together. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Jeff Shell wrote: And I think that's where I worry. With ZCML, name resolution happens very late. This seems to cut down on the problems that I've had with Zope 2 style configuration. If imports are in the top of the module, as most developers are used to doing, then they're executed as the module is imported for the first time. This is why I don't want 'configure.py' to be imported by other code if it can be helped. Zope 2 imports are ugly because of side effects. In the absence of side effects, it's better to import early to reveal ImportErrors early. This is probably the reason ZCML actually evaluates imports earlier than you suggest. 'import' is better and cleaner, but it's a situation where I worry about side effects unless the imports are outside of the top level of these hypothetical 'configure.py' modules. We've provided developers a way to achieve configuration with no side effects. I think this is a major accomplishment in the Python community--until now, there was no standard way to avoid side effects in Python code in general. With that problem solved, we should stop worrying about import side effects and make this new functionality thoroughly easy to use in all Python code. Hmm... now that I think of it that way, maybe it would be perfectly appropriate to create a Python-only ZCML for use outside Zope. Then Zope could use it if it wants to. Shane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On Thursday 22 December 2005 09:23, Martin Aspeli wrote: So it's very refreshing to see Zope 3 without ZCML. I hope the trend continues. I think Philipp makes what in my limited understanding is a very good point here: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-n eeds-to-do-less As said before, this idea was first expressed by Jim over a year ago, and we have been moving towards this model ever since. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On Dec 22, 2005, at 12:05 PM, Shane Hathaway wrote: Time and again people fail to realize that Zope 3 wants to create the low level framework right first, and only after that add high level simplifications and shortcuts to have less configuration and provide fastest developer exeperience. Of course people aren't attracted to Zope 3 yet because they feel it's complex. And there's a reason: it *is* complex. For now. So you don't think anyone but hard core Pythonistas should use Zope 3 yet? Does anyone think that code generation in the form of a starter package could help here? - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On 22 Dec 2005, at 18:09, Chris McDonough wrote: On Dec 22, 2005, at 12:05 PM, Shane Hathaway wrote: Time and again people fail to realize that Zope 3 wants to create the low level framework right first, and only after that add high level simplifications and shortcuts to have less configuration and provide fastest developer exeperience. Of course people aren't attracted to Zope 3 yet because they feel it's complex. And there's a reason: it *is* complex. For now. So you don't think anyone but hard core Pythonistas should use Zope 3 yet? Does anyone think that code generation in the form of a starter package could help here? Well, not me, I think code generation is an abomination from the devil ;) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
[Florent] Time and again people fail to realize that Zope 3 wants to create the low level framework right first, and only after that add high level simplifications and shortcuts to have less configuration and provide fastest developer exeperience. Of course people aren't attracted to Zope 3 yet because they feel it's complex. And there's a reason: it *is* complex. For now. [Shane] So you don't think anyone but hard core Pythonistas should use Zope 3 yet? [Chris] Does anyone think that code generation in the form of a starter package could help here? It would be a great experiment. Zope 3 currently inherits the Zope 2 tradition of starting with a full application, including a management UI, and developers add to that existing application. It would be valuable to explore an approach where developers start with a simple application (with no management UI) that they are expected to replace rather expand. I expect that developers would have a great experience initially that way. Most web frameworks have developers start with a minimal, replaceable application, but application developers write code in ways that hinder integration with other web applications even though they use the same framework. The theory behind Zope's configuration system is that application developers *will* be able to integrate after all, at least for a longer time than they can now. A starter package generator would test that theory. Shane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Chris McDonough wrote: On Dec 22, 2005, at 12:05 PM, Shane Hathaway wrote: Time and again people fail to realize that Zope 3 wants to create the low level framework right first, and only after that add high level simplifications and shortcuts to have less configuration and provide fastest developer exeperience. Of course people aren't attracted to Zope 3 yet because they feel it's complex. And there's a reason: it *is* complex. For now. So you don't think anyone but hard core Pythonistas should use Zope 3 yet? Does anyone think that code generation in the form of a starter package could help here? Yes. I'm hoping that the ArchGenXML project will produce that for Zope 3. I wonder how that work is progressing ... 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-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Jean-Marc Orliaguet wrote: Shane Hathaway wrote: ... The problem with ZCML is not the language (XML). Writing the same description in python would not address such issues as: - when looking at a component, how can I know how it is wired inside the application without doing a grep on 100 files? - when looking at the wires, how do I quickly get access to the components that they connect together? I agree. This is an issue with any system with lots of indirection. It's even a hassle with lots of inheritence, although at least base classes provide an avenue of search. This is all I need in order to understand how an application is built. If it was easier to navigate between the components by following the wires, there wouldn't be such an issue with ZCML I think. Maybe a GUI, or IDE would help a lot. Have you looked at apidoc? If not you should. It's far from perfect, but it's a great start. It needs more people contributing ideas. It could also be that ZCML is cluttered with too much information that really doesn't belong there. Yup. For instance ZCML should not be used for the application setup (for creating menus, actions, workflows, etc.) because this has nothing to do with connecting components. This could be done in python or be stored in archives in XML (.tgz, .zip, ..). Except that these all *are* components. Shane Hathaway wrote: Chris McDonough wrote: I assume this means you've given up on the idea of creating a GUI ZCML configuration tool, the? No. In fact, I've been creating the tool for the purpose of convincing myself that ZCML is right, even though I still believe it's wrong. :-) One thing I've learned from the GUI project, however, is that its greatest value is being able to *query* the configuration. It lets you answer questions like where are all the views named update.html?. That's valuable independently of the format of ZCML. This would be a good feature to add to apidoc. 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-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
Jim Fulton wrote: Jean-Marc Orliaguet wrote: The problem with ZCML is not the language (XML). Writing the same description in python would not address such issues as: - when looking at a component, how can I know how it is wired inside the application without doing a grep on 100 files? - when looking at the wires, how do I quickly get access to the components that they connect together? I agree. This is an issue with any system with lots of indirection. It's even a hassle with lots of inheritence, although at least base classes provide an avenue of search. This is all I need in order to understand how an application is built. If it was easier to navigate between the components by following the wires, there wouldn't be such an issue with ZCML I think. Maybe a GUI, or IDE would help a lot. Have you looked at apidoc? If not you should. It's far from perfect, but it's a great start. It needs more people contributing ideas. Yes, I have indeed. Though I was thinking about the development of new applications, not about API documentation. Probably this could be done with the Eclipse IDE: for instance when creating an adapter, I would first register an empty adapter object then I would add code to some skeleton class. And conversely, when browsing the code, I would get the list of adapters that use the code, but in a live manner, i.e inside some integrated development environment that support zope3 types of components (adapters, utilities, ..). Maybe an Eclipse plugin would do.. This key is to be able to see both the components and the relations between the components at the same time and to rapidly switch between the two views. That would improve productivity a lot. It could also be that ZCML is cluttered with too much information that really doesn't belong there. Yup. For instance ZCML should not be used for the application setup (for creating menus, actions, workflows, etc.) because this has nothing to do with connecting components. This could be done in python or be stored in archives in XML (.tgz, .zip, ..). Except that these all *are* components. These are *implemented* as components, indeed. But the data registered in ZCML is not the data used to register new components, it is the data used to create new instances of a same component by passing it as parameters to the component's factory. For example the browser:menu directive registers new menu instances (not new types or classes of menus, there is only one type of menu called browser:menu). I think I got burnt by this confusion by mixing those levels (e.g. portlets as components and portlet instances created from a same portlet component). Now I have placed the definition of components inside ZCML directives and the application setup part is done with .zip or .tgz, or xml files (in the spirit of CMFSetup or GenericSetup). The former are registered during the configuration phase (configure.zcml) , the latter are loaded after the application server has started. They could even be loaded later on by doing TTW data imports ... /JM. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: ZCML, practicality, purity (was Excellent perspective...)
On 12/22/05, Shane Hathaway [EMAIL PROTECTED] wrote: [Shane] Are you sure ZCML is The Right Way? I know its purpose (since I helped invent Zope 3): to combine configurations by multiple developers without imposing a particular workflow. However, I maintain that Python code could do the job better. The Python code I have in mind is not the same as Jeffrey's examples. I'll elaborate if there's interest. [Pete Taylor] *ping* for interest in elaboration on the code you have in mind... Ok. Here are two snippets that express the same thing. First in ZCML: browser:skin name=Rotterdam interface=zope.app.rotterdam.Rotterdam / browser:resource name=zope3.css file=zope3.css layer=zope.app.rotterdam.rotterdam / Now in Python (hypothetical): from zope.app import rotterdam def configure(context): context.browser.skin( name='Rotterdam', interface=rotterdam.Rotterdam) context.browser.resource( name='zope3.css', file='zope3.css', layer=rotterdam.rotterdam) All functionality and capabilities of ZCML are retained, but there are important, subtle differences. - I could conceivably type configuration directives at the interactive Python prompt. I could use the standard dir() and help() functions to find out what directives exist and how to use them. This reminds me a lot of the initialize(context) in Zope 2 products. I still have very mixed feelings about that system, most of it due to lack of knowledge or understanding on my part of how to write a good 'initialize()' function, and what should take place in there (configuration) versus elsewhere in that __init__.py module. One thing that I like about ZCML is control over order, especially in regards to configuration. What order things are initialized in, regardless of alphabetical order. So if I have a lot of packages that depend on 'hurry.file' being configured, I can ensure that it happens before my files. This was a problem that I had with Formulator in Zope 2. If I had my own widgets defined in my own product, the behavior of registration was a little bit different depending on whether my Product's name came before or after Formulator alphabetically. I also _really_ like how well documented ZCML is - especially in comparison to the rest of Zope 3. APIDOC captures a lot of things, but the ZCML menu is by far the most useful and usable. There are still too many unknown interfaces and APIs inside of Zope. It's no fault of APIDOC. There are a lot of interfaces out there, and sorting and presenting them in a cogent way is difficult. ZCML, on the other hand, is a limited vocabulary, and in a tool like APIDOC I've found it to be more discoverable. That is EXTREMELY important to me. dir() and help() at the Python prompt are nice. But so is schema-driven apidoc reference material - especially if that schema remains used as / close to what's used to transform incoming data. People don't always spell out parameters in doc strings clearly. Interface schema fields, on the other hand, give a great view about what's required, what's not, and what format it should be in. Other problems that I've had with Python based configuration in the past has involved not knowing when to do the configuration. Do I want to register the class I just defined in the module code? class Foo(...): pass registerAsFooable(Foo) Well, that tends to lead to problems, since it takes away from being able to use Foo without also having to carry its registration which may not be wanted or required by a client of Foo. These are the sorts of things that one has to define and restrict early on, because once a bad example gets out there in the wild and other people start copying it. Webware had 'configure.py' files and I *HATED* seeing them. They looked sloppy and weird, stuffing things into dictionaries whose structures I didn't know or understand. But if that were a route one decided to use, one would have to lay down VERY strict rules. Otherwise we lose all the benefits of the Component Architecture and start heading back into a free-for-all mess. Such rules might be: no other package or module code should import a configuration module. Only the configuration machinery should ever do it. With Zope 2, I never was able to write and keep a good personal rule about how to deal with a Product's __init__.py module, and it would be involved with doing things besides configuration. Modules and objects that were imported in the top of the __init__.py module probably should have been imported inside initialize(context). Only and only and only and only 'configuration' logic should be in a configuration module. The module HAS to provide and only provide an IComponentArchitectureConfiguration interface, and should export only the names in that interface. Alarms and warnings should go off otherwise. I just believe - heavily - after
