[Zope3-dev] Re: what is ZCML?
Shane Hathaway wrote: 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. true, but zcml + configuration system is how you currently access this feature. The runtime execution of configuration + having a unified configuration format has been fairly important to creating systems that have to deal with backward compatibility in a transparent, organized way(I'm thinking of Five here). in zope3 such monkeypatch madness isn't a concern. but zcml isn't used just in zope3 anymore. -w ___ 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: what is ZCML?
Jeff Shell wrote at 2006-3-15 14:26 -0700: ... Anyways, I don't mind if someone wants 'browser:addform' as an add-on. But I don't think those things belong in the core. If someone wants to make a package that lets them build a web site using nothing but ZCML to glue a bunch of crap together! then lets have it. But not in the core. It's limiting. It's restrictive. The bit that it makes hard is the bit that most people get to at some point in the lifecycle of their web application. Why make them switch paradigms at that point? Maybe, because until that point it made life easier? I am very happy to use high level abstractions (provided they have well chosen names -- browser.addform seems quite good -- and a clear semantics) and start only to dig deeper when necessary. I treat a car as a black box with a well defined set of functions. Only when I reach the limits, I search deeper and may learn that there is a motor that can be tuned... ... That makes the integrators job much harder. If browser:view, browser:page, and zope:view all went away today in favor of subclassing from formlib.Page, BrowserView, or something else common that provided the core full-view-page pieces (publishTraverse, browserDefault, __call__) and only zope:adapter was used as the ZCML directive, it would be much easier (I think) to start providing views that can be better augmented by integrators. (Besides, I think 'integrators' are better served by the programming language. Anyone who thinks they can just download a bunch of random components and build a unique web site with nothing but XML is deluding themselves). Things I agree with... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: 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. I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with back to Python as a solution than more traditional admins / integrators would be. Big directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. The fact that such developer-admins are the primary users of ZCML so far is due to the small size of the Zope3 market to date. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo 8+DrkkvhQFQDB8WGCSC70j4= =X/7J -END PGP SIGNATURE- ___ 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: what is ZCML?
On 3/15/06, Tres Seaver [EMAIL PROTECTED] wrote: I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Isn't that always the case though? Besides - I don't think there's anything more vague than the concept of 'policy'. What policy? Where did it come from? Who wrote it? In what? Anyways, I don't mind if someone wants 'browser:addform' as an add-on. But I don't think those things belong in the core. If someone wants to make a package that lets them build a web site using nothing but ZCML to glue a bunch of crap together! then lets have it. But not in the core. It's limiting. It's restrictive. The bit that it makes hard is the bit that most people get to at some point in the lifecycle of their web application. Why make them switch paradigms at that point? ZCML can only carry people so far. And we can only push it so far (if that's the path we follow) before it starts developing the needs for more programming language type features like full expressions. I say we cut it down to size now. Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with back to Python as a solution than more traditional admins / integrators would be. Big directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. But the developers have to write the ZCML for their products. That's the current story. The bigger and weirder and harder that universe becomes, the less likely that the developers are going to actually use it 'correctly'. Initial experiments with viewlets and content providers were the first things that proved the flaws of browser:page versus browser:view. In browser:view you can specify a 'provides' attribute. It becomes very useful when you want to allow for viewlets to show up or not show up for certain pages. It's a powerful feature of extensibility and integration, I think, to support viewlets/content providers. But if developers don't know that: (a) Any implements() statement on their view class is likely to be ignored. (b) Only browser:view (and zope:view) allow specifying a provided interface that a viewlet or content provider can match against. browser:page does not. (c) Writing for viewlets and in small code / small fragments (and using the update/render paradigm in general) is the easiest way to make the interface extensible. That makes the integrators job much harder. If browser:view, browser:page, and zope:view all went away today in favor of subclassing from formlib.Page, BrowserView, or something else common that provided the core full-view-page pieces (publishTraverse, browserDefault, __call__) and only zope:adapter was used as the ZCML directive, it would be much easier (I think) to start providing views that can be better augmented by integrators. (Besides, I think 'integrators' are better served by the programming language. Anyone who thinks they can just download a bunch of random components and build a unique web site with nothing but XML is deluding themselves). Administrators (if we're talking about system administrators) may be better served by tools and components that expose certain configuration options to ZConfig (or whatever might replace it), along with the tools to generate the skeletons for that. RDBMS connections, tag blacklists if you will, whatever. I don't see anything in the current ZCML that actually makes it obvious from downloading and installing Product X (especially if installing means checking out from subversion or unpacking a .tgz) which elements in it need special configuration like - which mail server to use, which MySQL login to use, etc. Instead the ZCML is full of content, adapter, utility, browser:* directives, most of which are essential to that package or application. You may not want to custom configure 95% of that stuff. Most of that's just to load the application up into Zope. If there's a tag blacklist or RDB connection or other hypothetical administrative feature, it's buried amongst all of the developer stuff anyways. There's no nicely commented file like the default Zope 2 ZConfig file that details all of the options, why they're there, how to change them. Instead it's 500 lines of code registering 27 views, 14 menu items, and a nice chinchilla. How does that ZCML benefit an administrator or integrator that you feel must be protected from all of the Python code? Don't you think that, to an outsider, digging for:: viewlet name=kbase.importzipform
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: 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. It spells out lots of site policy which must *not* creep back into the software. 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. Really? You have no options which an admin might want to change, either on a site-wide basis or within a single folder? How about choices like whether to accept HTML 4.0 versus XHTML 1.0? What about tag blacklists? 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) We need to get beyond the idea that Python is the ideal place to spell everything. It is particularly bad to have to modify the software shipped by the developer in order to change policy, which is where we are going if we continue down this road. Having to accept choices made by a component developer is a barrier to reuse; we won't win brownie points for all our cool components if we make it hard to use a comoponent without accepting either *all* or *none* of its configured policy choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFhdD+gerLs4ltQ4RAptSAJ4lvBZ2f7iwodYUP8l9J4j+nqoYcQCgr5qb c4HIIpb1Kkm/KuQ7yMYiGdU= =F/SR -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
