Philipp von Weitershausen <philipp <at> weitershausen.de> writes:
> The problem is uncontrolled ZCML directive proliferation. It's "bad" enough > that you have to familiarize yourself with a new API when dealing with a 3rd > party Zope package. But having to learn a new set of ZCML directives?!? I > think many people would be skeptical. Me included. Or a new python API... your package will have to come with documentatio about how it is to be used. If Zope encourages a consistent way of demarcating what is ZCML-configured, what is python-configured and what is not configuration at all, this problem will go away. > As we have learned that we can reduce nearly all component tasks to adapters > and utilities, many tasks revolving around registration and configuration of > policy also only involve adapters and utilities. By using those "elementary" > directives we can stimulate the learning process for developers ("there should > only be one way of doing things"). Yes, you might have to use two or three > directives instead of just one new one, but you'll know what you're doing... > And you'll remember it in 2 months. I think that's more valuable than saving a > couple of lines today. There is always a balance between the aesthetic beauty of reducing everything to a few axiomatic principles, and the way people think. I think you'll find that many people get confused by the view/multi-adapter duality. Yes, it's very neat when you finally get it, but it took me a long time to get my head around it (partially, I admit, because I was reading poor documentation... when I read your book, it made a lot more sense). Be sure to draw a clear line between what things are the same because the implementation lends itself to use the same primitive components, and what things are actually semantically equivalent. > That said, there might still be a small percentage of cases where custom > directives are a valid tool. I can accept their being on the same namespace as > others. In fact, I would like it to be that way, reducing the amount of dead > chickens (namespace declarations). I think this is based on a misunderstanding of how XML works (or should work) combined with a somewhat irrational fear of writing a few extra letters. You don't have to declare namespaces you don't use in any particular file, nor do you have to stick to long-winded prefixes if you don't want to. The URIs of namespaces are unique identifiers and can be quite short (e.g. http://zope.org/dtd/core). Ideally, they should resolve to DTDs that can be used for XML validation and by tools to create code-completion etc. Now, if Zope decides that it has a sufficiently small set of concepts to warrant keeping them in a single namespace, that's probably a good thing - less to learn, less to remember. If it turns out there are very clear components with different areas of use, having different namespaces may well work. I'm not a fan of the core vs. browser namespace separation at the moment, for example, but I could see how something radically removed from the core Zope use case would find use for a separate namespace. But third party products that have not (yet) been rolled into core Zope must have their own namespace, to avoid clashes, to permit validation, and simply to meake it clear what is being provided by the third party product. Martin _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com