[Zope3-dev] Zope 3 Source organization

[Shane Hathaway]

Phillip J. Eby wrote:
> IAnotherAppView = protocols.Variation(ISomeKindOfView)

That's an interesting choice of terminology.  In the XML-based 
configuration system I just put together for Ape, I used the word 
"variation" to extend configurations.  I was quite happy with the way it 
worked out and I wonder if Zope 3 ought to adopt a similar concept.  I 
also wonder if the concept has weaknesses.

Variations are a generalization of the CMF "skin" concept, in that 
variations let you provide multiple configurations, but variations apply 
to all configuration directives, not just presentation directives. 
Package authors can write closely coupled directives with the confidence 
that others can override their directives easily using variations.

Here is a sample of apeconf.xml:

<mapper name="AccessControl.User.UserFolder"
   extends="base" parent="root">
  <serializer name="data"
    factory="apelib.zope2.security.UserFolderSerializer" />
  <variation name="filesystem">
   <gateway name="data" factory="apelib.fs.security.FSUserList" />
  </variation>
  <variation name="sql">
   <gateway name="data" use="sql_userlist" />
  </variation>
</mapper>

This says that there should be a mapper that serializes UserFolders.  To 
serialize a UserFolder, use the base serializers along with a 
UserFolderSerializer.  To load or store state for a particular 
UserFolder, use the base gateways along with a different component 
depending on whether you're storing to the filesystem or in a SQL 
database.  A single configuration file can specify multiple variations.

Someone else could decide they want to reuse this mapper configuration 
to store in an LDAP database.  They could do it just by writing an 
LDAPUserList class and adding the following directive to their own 
apeconf.xml:

<mapper name="AccessControl.User.UserFolder">
  <variation name="ldap">
   <gateway name="data" factory="mypackage.LDAPUserList" />
  </variation>
</mapper>

To use this configuration, you ask for the "ldap" variation of the root 
mapper.  Ape assembles the mapper and returns it.  Variations can extend 
other variations, although the current implementation doesn't provide a 
way to extend anything other than the default variation.

I didn't use ZCML because I wanted to research possible improvements to 
ZCML without being encumbered by the choices ZCML makes.  I avoided XML 
namespaces, used elements instead of attributes, allowed elements in 
elements, and represented directives as class instances.  I intend to 
write documentation not only on how to write apeconf.xml files, but also 
on the configuration model.  FWIW.

Shane