[Zope3-dev] How does Zope.Configuration work?

[Guido van Rossum]

> I think we're hitting a terminology barrier.  I see three actors in
> this picture:
> 
>  - Product/Component developers.  These are the guys that build
>    content types and reusable applications.
> 
>  - Site builders.  These guys select & configure packages, and might
>    want to replace individual view components to add integration with
>    components from different sources.
> 
>  - Site admins.  These guys just want to control permissions, and
>    should need to do as little as possible with site configuration.
> 
> I think most of the ZCML should be produced by the Product/Component
> developers and changed by the Site builders only when needed.  Site
> admins *won't* change ZCML or any other configuration if they can get
> away with it, and should never need to make large or complicated
> changes.

There's stuff in the job board ZCML that should be off limits for site
builders, because it encodes essential logic of the job board app.

For example, this statement:

<browser:view
	for=".JobBoardEx.IJobList."
        name="_traverse"
        factory=".JobBoardEx.JobListView.JobListTraverser"
/>

installs a custom traverser without which none of the app works.
Replacing it is not an option, its implementation is tied intimately
to the rest of the app's implementation.

Several view are also configured this way.  Forcing the app developer
to open up his app to mistweaking by the site builder makes me feel
uncomfortable.

Suppose the site builder comes to the developer with a complaint: the
jobboard is broken.  After a long debugging session it becomes clear
that the site builder changed the configuration.  Who is to blame?

If the site builder had touched the Python code, the answer would have
been easy: don't touch what you don't understand.  But the site
builder can reasonably expect that tweaking the configuration is his
prerogative, and he might be surprised at how brittle the app is in
the light of config changes.

If there really is no way to avoid putting some app logic in a ZCML
file, maybe there should be two ZCML files, one containing the
"tweakable" configuration and one containing the app logic.  Then the
latter can be included by the former (or vice versa, it doesn't really
matter) and the app logic file can be marked as "don't touch" in
large, friendly letters.

--Guido van Rossum (home page: http://www.python.org/~guido/)