[Zope3-dev] One namespace for ZCML

[Philipp von Weitershausen]

Martijn Faassen wrote:
>> 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)

...

> * 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 guess most of these fall under the "registering something that isn't a
utility or adapter" category which is fine. Though I wouldn't be
surprised some of those registrations could be boiled down to simpler,
Zope-3-style things like menu items or utilities. Oh wait, you mention
that yourself :).

> * a way to register an XSLT renderer.
> 
> * registering XML importers and exporters.

These two immediately triggered "adapter" in my mind :).

> 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 agree on the eventuality. It's important, though, that we do try to
find a good match between the Zope 3 ways of doing things and the
historical baggage. In Zope 3 we have developed a nice way of looking at
things and fit them into very simple concepts. It should be preserved.

Btw, I find it a bit scary that you're trying to replace an install
method with a lot of ZCML directives. I'm not sure I would welcome a
procedure expressed through configuration. It seems like some of these
problems are better tucked away using a deployment framework like
GenericSetup. But then again, I'm not really familiar with Silva and
that install.py thing.

>>> 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.

No worries, I got the tone of the message. However, to every satire
there's a true core message, as you're pointing out yourself. I too am
concerned, but I also think that because dotted names actually have a
meaning, they might be handier in the end than cryptic short forms.

And then there's also the point of intrinsic information of a component
that we're currently putting into ZCML but are starting to put into
Python. I has already reduced the amount of dotted names necessary.

> 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. :)

At least it would give you the possibility to define and use XML
entities for them :). Seriously, though, I wouldn't be sure of my vote
for a system like that. As said, dotted names have a meaningful
background (Python import paths). Abbreviations most likely don't. I
rather build something that makes sense than one that relies on too many
naming conventions...

>>>> 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.

I think the 'zcml' namespace should be separate from the 'zope' one
because 'zcml' is meta-ish whereas 'zope' is about actual and factual
directives. I would rather see 'meta' directives folded into 'zcml'
(like I propose in the proposal).

>> 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.

Seems like a good distinction, though it also would suggest that perhaps
everything living in 'zope.*' packages should only use one namespace
('zope'), just like other packages would use other namespaces.

*That* would be a ZCML namespace policy I would be comfortable with.

Philipp