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] Re: [Zope-dev] Two visions
On Tuesday 28 February 2006 00:22, Encolpe Degoute wrote: Lennart Regebro a écrit : | OK, some initial, fuzzy comments: | | On 2/27/06, Jim Fulton [EMAIL PROTECTED] wrote: |2) In an alternate vision, Zope 2 evolves to Zope 5. | | - Zope 5 will be the application server generally known as Zope. It | will be backward compatible (to the same degree that Zope 2 | releases are currently backward compatible with previous Zope 2 | releases) with Zope 2. Zope 5 will similarly be backward | compatible with Zope 3 applications built on top of the current | Zope 3 application server. | | Note that Zope 5 will leverage Zope 3 technologies to allow a | variety of configurations, including a Zope 2-like configuration | with implicit acquisition and through-the-web development, and a | Zope 3-like configuration that looks a lot like the current Zope | 3 application server. Maybe, there will be a configuration that | allows Zope 2 and Zope 3 applications to be combined to a | significant degree. | | This overwhelms my complexity sensor. :-) | | I like the vision of Zope2 becoming a set of extra packages you | install for Zope3, to get backwards compatibility. Maybe this is the | same as what you call Zope 5, maybe not. I vote for this one. There's already Five product to help Zope2 products to become to be Zope3 compatible. Now, it's to Zope2 developpers to do the migration step. +1 also, though I've done next to no pure Zope 3 development, I've done enough development with Five to realize that the major problems with developing in this manner come from having to deal with artifacts of Zope 2. As a result, I think it's best to componentize the bits of Zope 2 that provide useful features missing from Zope 3, and abandon the rest. Being able to transfer existing Zope 2 applications with little effort is not a terribly important goal IMO, especially if doing so requires making Zope 3 more monolithic and Zope 2ish. Alec ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
