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

Zope3-users mailing list

Reply via email to