[Zope3-Users] Re: ZCML, practicality, purity (was "Excellent perspective...")

[Jean-Marc Orliaguet]

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

/JM.