Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
The problem with ZCML is not the language (XML). Writing the same
description in python would not address such issues as:
- when looking at a component, how can I know how it is wired inside
the application without doing a grep on 100 files?
- when looking at the wires, how do I quickly get access to the
components that they connect together?
I agree. This is an issue with any system with lots of indirection.
It's even a hassle with lots of inheritence, although at least base
provide an avenue of search.
This is all I need in order to understand how an application is
built. If it was easier to navigate between the components by
following the wires, there wouldn't be such an issue with ZCML I
think. Maybe a GUI, or IDE would help a lot.
Have you looked at apidoc? If not you should. It's far from perfect, but
it's a great start. It needs more people contributing ideas.
Yes, I have indeed. Though I was thinking about the development of new
applications, not about API documentation. Probably this could be done
with the Eclipse IDE: for instance when creating an adapter, I would
first register an empty adapter object then I would add code to some
skeleton class. And conversely, when browsing the code, I would get the
list of adapters that use the code, but in a "live" manner, i.e inside
some integrated development environment that support zope3 types of
components (adapters, utilities, ..). Maybe an Eclipse plugin would do..
This key is to be able to see both the components and the relations
between the components at the same time and to rapidly switch between
the two views. That would improve productivity a lot.
It could also be that ZCML is cluttered with too much information
that really doesn't belong there.
For instance ZCML should not be used for the application setup (for
creating menus, actions, workflows, etc.) because this has nothing to
do with connecting components. This could be done in python or be
stored in archives in XML (.tgz, .zip, ..).
Except that these all *are* components.
These are *implemented* as components, indeed. But the data registered
in ZCML is not the data used to register new components, it is the data
used to create new instances of a same component by passing it as
parameters to the component's factory.
For example the browser:menu directive registers new menu instances (not
new types or classes of menus, there is only one type of menu called
browser:menu). I think I got burnt by this confusion by mixing those
levels (e.g. "portlets" as components and portlet "instances" created
from a same portlet component). Now I have placed the definition of
components inside ZCML directives and the application setup part is done
with .zip or .tgz, or xml files (in the spirit of CMFSetup or
GenericSetup). The former are registered during the configuration phase
(configure.zcml) , the latter are loaded after the application server
has started. They could even be loaded later on by doing TTW data
Zope3-users mailing list