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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
