[Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives

Dominik Huber dominik.huber at perse.ch
Wed Feb 22 05:26:13 EST 2006

Philipp von Weitershausen wrote:
> [...]
>> I would vote to leave at least the class/factory and class/implements
>> subdirectives.
> The class/implements subdirective is debatable because putting an
> interface on a class might be considered some sort of policy. So I don't
> feel too strong about it.
Thanks :)
> The class/factory case however is clearly about automation.
Yes, one aspect. This aspect is very important too. I love this 
automation and I'm probably not the only one. Look at Gary's statement 
"I'll miss class/factory,...".
> As demonstrated in the proposal, the Python version with a simple utility directive is only two or so lines longer and essentially moves most of the information from ZCML to Python code.
The move from ZCML to Python is often better, but not always. I tried to 
sketch the use case *including a class from an external library into an 

My balance based on the attached example [1] summarizes the following:
A) Extensive today: 10 text-lines in zcml
B) Lazy today: 6 text-lines in zcml
C) Exentsive proposed: 1O text-lines in zcml, 8 text-lines in py-module
+ retyping the IFactory-import each time
D) Lazy proposed: 1O text-lines in zcml, 8 text-lines in py-module
+ retyping the IFactory-import each time

So, the proposed solution is about 3 times (*not* 3 lines ;) costlier 
than the laziest-manner.

> It also reuses the well-known utility directive which makes registering factories very coherent: No matter whether they are custom or based on a callable like a factory from class, you just use the utility directive.
> Coherence is one of the initial problems I state in the proposal so I
> rather feel strongly about the class/factory case.
I really support coherence and less-magic attempts, but in this case the 
price is definitely to high and the intended simplification is fairly 

The class/factory and createObject-pattern was always understandable for 
the Newbies I've met during the mini-sprints. The whole 
component-architecture in particular the adapter- and utility-mechanism 
was much more magic for them.

Automation will stay a magic, but it enables often people to do things 
they don't fully (deeply) understand. IMO it's more important to offer 
coherent magics on a certain application-layer than to evangelise 
assembler or even quantum mechanics. As well there the magic will come 
back at a certain point on a deeper application level :)

Still a very strong -1 on removing class/factory.



A) Extensive today
Today I have to write one ZCML...:

<class class=".alias.SydneyBristow">
      title="Agent Sydney Bristow"
      description="Sydney is an undercover agent working for the CIA"

B) Lazy today

or in the laziest manner (B): 

<class class=".alias.SydneyBristow">
  <factory />

Remark: Afterward I can use the zope.component.createObject("external.library.SydneyBristow") to create

C) Extensive proposed
After the proposed change I have to do the following: 

additional module for example alias.py:
from zope.component.factory import Factory
from external.library import SyndeyBristow

sydneyFactory = Factory(
    SyndeyBristow,                     # a callable, e.g. a class
    title=(u'Agent Sydney Bristow'),
    description=(u'Sydney is an undercover agent working for the CIA')

ZCML to register the class and the factory utility:

<class class=".alias.SydneyBristow">

<utility component=".alias.sydneyFactory" 

D) Lazy proposed ---------------- dito - 2 text lines

More information about the Zope3-dev mailing list