[Zope3-dev] One namespace for ZCML

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
[snip]
>>Moreover, sometimes a package introduces new ways to configure
>>components. Five does so, for instance, and Silva will too eventually.
> 
> 
> I would really like to hear what kind of directives you imagine for Silva here
> (and what you mean by "new ways to configure components").

The following are candidates, though note I haven't thought this through 
deeply for any of them:

* a way to register a Silva content object.

* a way to register a content object version.

* a way to register a Silva metadata set.

* registering directory views (could go into CMF, though Silva is not 
using it directly now)

* a way to register an XSLT renderer.

* registering XML importers and exporters.

* registering a silva service into the Silva root

* configuring which objects can be addable.

* setting up zope 2 permission/role mapping in Silva root.

* setting up the zope 2 catalog indexes.

I think some, or even all, of these can probably turn *eventually* into 
Zope 3-style approaches directly - probably services will become some 
sort of local utilities, and directory views will become Zope 3 view, 
XSLT another, and the importers/exporters will become some sort of 
adapters, addables menus.

The emphasis is on eventually, as I certainly expect it to be useful in 
a transition phase to clean out Silva's current grotty install.py and 
replace it with ZCML that doesn't require significant refactorings of 
Silva yet. Replacing this stuff with native Zope 3 components is 
generally a major task.

I expect a very similar story applies to CMF, and again to CMF-based 
systems like Plone.

>>Sometimes a new, short directive is a lot easier to
>>remember than to remember long.dotted.names.pointing.to.places and 3
>>directives. Having to remember (or worse, look up) long dotted names is
>>extremely common in ZCML and I consider it at least as big a problem as
>>having to learn directives.
> 
> I agree. Many of these long dotted names belong into Python, though.
>  
>>Let's use abstraction and naming things where it makes sense.
>>
>>Heh, perhaps we need to go the other way and add a namespace directive
>>for long dotted names instead. :)
> 
> -1.

I put in a smiley, but I'm serious about the underlying problem of 
exposing a lot of long dotted names into Python modules into ZCML. I 
wonder whether we can do things to make this look simpler. If the dotted 
names were not hiding in attributes but in element content, we could 
come up with some kind of XML vocabulary for them, even. :)

>>>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).
>>
>>Namespace declarations are not dead chickens. They're things that the
>>XML language requires. Indentation and colons are not dead chickens in
>>Python either. *particular* namespace declarations may be unnecessary -
>>but not dead chickens, just perhaps the wrong solution.
> 
> Yeah, sorry, bad wording. I just think having to declare 3 to 5 different
> namespaces on the top of the file of which some have no apparent meaning or
> distinction seems like clutter to me.

Some indeed have no apparent meaning and distinction; I think 
zcml:condition could be safely folded into Zope's namespace. When I see 
apidoc or wfmc I can identify what is involved, though - possibly they 
can still be eliminated but they definitely have meaning to me.

In the documentlibrary, so far we've only used two namespaces, zope and 
browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and 
zcml. I think eliminating the 'zcml' namespace would get us down to 2 
or less declarations for most .zcml files.

> Note that I absolutely see the necessity for namespace declarations. For
> example, I would like to see ZPT require the declaration of TAL, METAL and
> I18N namespaces. Note that there the entire namespace story is different.
> There they are used for what I think namespaces are intended, separating
> several XML models (e.g. the HTML model from the additional TAL/METAL/I18N
> model).

I think Zope 3 extensions extend the Zope 3 XML model. They're less 
different than combining XHTML with TAL, but I still see a core 
vocabulary with potentially arbitrary extensions.

Regards,

Martijn