[Zope3-dev] ZCML alternative

[Jeff Kowalczyk]

> - Allow a site manager to configure how software will be 
    used *without* modifying the software.  With your 
    proposal, the site manager would have to modify the 
    original source to make changes.

[Jeff] In .NET, the metadata are a component layer of their own,
instanced depending on where they apply. The metadata has an exposed
API, in effect, which is discussed in that O'Reilly article. It can be
emitted by an [attribute] syntax, or program code, which can include
parsers of configuration files, code in constructors, code in library
wrappers, as well as handlers for custom attributes.

The intention is for later configuration to override, but where the
programmer knows some subset of metadata will usually apply, they can
build it in, and even enforce it, if need be. Their approach seems to be
allowing you to configure metadata where you first or best know it, and
the idea I'm suggesting here is that sometimes you can decide upon good
defaults when writing the python component, and in those cases, it will
be more productive for the average Zope-specific component developer to
manage a few terse attributes in the Zope-specific source as a
complement to the bigger picture of the external ZCML metadata
structure.

- The component author might create attributes directly in the source if
they're intrinsic to the class or its intended use. These would
typically be things like hooking the view mechanisms up, things that are
intimately related to the logic of the python source being worked on,
and that the application developer and deployment technician may not
have inclination to learn. Zope components using attributes would have a
compact metadata for required Zope-isms, easily kept synchronized with
the source, and limited in scope to what they need to accomplish their
intended functions. They wouldn't specify deployment-level details like
security unless that was their specific single-use purpose. 

- The application developer can set, override and add to the attributes
in the assembly (an instance of a group of components) metadata e.g.
modifications to the ZCML at that level or the z3.py layer ZCML that you
mentioned today, or code to emit instances of the metadata.

- Deployment technicians have another opportunity to override and add to
the attributes when configuring the deployed application. ZopeTop might
have TTW features to support their more limited ZCML configuration
needs.

> - We want to minimize, or eliminate changes to source to
>   make classes usable in Zope.

[Jeff] Existing python libraries wouldn't be modified, the only python
source that would use declarative attributes at all are new components
that are specifically written for Zope and have expectations of and
responsibilities to Zope's machinery. General purpose Python libraries
that don't have need for knowledge of Zope would remain unmodified,
using ZCML or other mechanism (Shane's approach) to create the metadata
instances that would give the library access to, or permissions in, the
Zope machinery.

I'm primarily thinking of attributes as a way to streamline Zope
component development. We will have a vast number of components
developed by end users, since Zope gives people a good reason to develop
content objects as components as well as the usual functional
components.