Philipp von Weitershausen wrote:
Martijn Faassen wrote:
[snip]
* a way to register an XSLT renderer.
* registering XML importers and exporters.
These two immediately triggered "adapter" in my mind :).
XSLT renderer may be a view, that's how we use them now. I think it's a
candidate for a fairly easy transition to Zope 3 style concepts, in fact.
There are subtleties with XML importers that don't really map to
adapters directly, at least not in a simple way - you want to register
different importers for certain XML tags.
[snip]
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.
Sure, but I want my silva namespace so I don't pollute the Zope 3 space.
:) Same reason I'm happy with the five namespace.
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.
Silva's 'install.py' does a lot of stuff that really should be
declaration, not procedure. Registering metadata sets for content types,
registering views, etc, etc. Then extensions to Silva also do the same
thing. GenericSetup would make sense for some of it, but I suspect
fairly little, except of course that right now lots of Silva's
configuration, often unnecessarily, ends up in the ZODB.
[snip]
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.
Yes, I saw that point of yours in another thread replying to me there,
and I think that's a very good point. Anyway, in my attitude to ZCML I'm
for piecemeal evolution right now - I don't think ruthless refactoring
is really necessary, but we can get quite ruthless on certain directives
or attributes of certain directives.
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...
Agreed; this needs to be thought through carefully. We don't want to
replace dotted names with a lot of shorter stuff you need to memorize
anyway, either. It needs to be somehow predictable, and perhaps dotted
names are the best we can do, if we can at least get rid of some of them
and move it into Python. It's just an interesting area to think about.
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).
zope:include and friends are meta-ish too though. Moving those into a
separate namespace would suddenly grow the amount of namespaces necessary.
Perhaps folding the meta namespace (+ zcml) into zope is actually
something we can explore. The meta namespace should be a fairly solid
XML vocabulary after all.
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.
I am not saying I agree with this proposal, but it's a direction I'd not
be against exploring. This means though that certain Zope extensions
that really add extension specific namespaces, such as email, need to be
removed from the Zope 3 core; I don't want the email extension specific
directives to end up in the general component configuration vocabulary.
Same with the workflow story.
This ties into the whole 'what is a Zope 3 extension and what is core'
discussion. It could be that if we move stuff into extensions you might
closer to what want you want while nothing changes to ZCML, if at least
you install these zope extensions first. :)
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
