[Zope3-dev] ZConfig schema extensibility q's

[Phillip J. Eby]

At 12:14 PM 10/3/03 -0400, Fred L. Drake, Jr. wrote:

>Phillip J. Eby writes:
>  > Whaaaa???  I've never used the null datatype for the schema, and I can't
>  > imagine ever wanting to.  But if I did, why couldn't I just say
>  > datatype="null" or datatype="ZConfig.sometype"?
>
>Interesting.  Zope itself doesn't use "null" either, so maybe my
>expectation here is just wrong.  I generally see the top-level
>configuration as a bag of stuff, but it's not so unreasonable to
>disagree.

I see ZConfig as a serialization format for encoding an entire 
application's object structure, where the top level object is invoked to 
run the application.  Thus, a config file can be made executable with an 
appropriate #! line.  This makes creating "instances" of an application 
very simple if it has no other files to worry about, and I therefore find 
it superior to e.g. using command line switches to specify where to find a 
configuration file, and then writing code to read and manipulate the 
configuration data.

In essence, I just have a standard ZConfig loader that needs to be told the 
URLs of the schema and config files, and then it can "run" any ZConfig 
file, provided that the top-level schema sets a datatype that implements 
"ICommandLineApp".

So, I suppose I can see why one might use the "bag of stuff" approach if 
you were retrofitting an existing application that used a "bag of stuff" 
configuration approach, but I can't imagine wanting to write a *new* 
application that way.

While it might seem you'd have to write your app classes around ZConfig, 
it's really not the case.  For PEAK, I simply added a 'fromZConfig()' 
constructor classmethod to my "Component" base class, that handles 
translating from a ZConfig section "bag of stuff" into attribute 
assignments on the newly created object.  So, I can in principle configure 
any PEAK component by defining a suitable ZConfig schema for 
it.  Voila!  ZConfig therefore becomes a format for serializing an 
application's component structure.  (My section and schema 'datatype' 
attributes just always end with '.fromZConfig'.)


>  > I'm baffled here.  If you're *not* extending another schema, of course no
>  > datatype is no datatype.  If you *are* extending a schema, then no 
> datatype
>  > means inherit the datatype.  I don't understand why you find this
>  > confusing.  It's no different, IMO, than the code:
>
>It depends very heavily on what your "base" datatype does.  Given that
>something can be written which is usable the way you describe, it
>should be fine to allow that to be "inherited".  Ok, I'll back off on
>this one.
>
>  > If you need to be able to turn a datatype *back* into a null in an 
> extended
>  > schema, why not just have some datatype like "ZConfig-Section" 
> available as
>  > a standard datatype?  Then you say, "if no datatype is defined or
>  > inherited, the default datatype is ZConfig-Section".
>
>That's currently spelled "null", so that option remains available.

So, does that basically mean that:

http://mail.zope.org/pipermail/zope3-dev/2003-September/008647.html

is the way we should go?  (I.e. no inheritance of valuetype, and 
keytype/datatype must match on all bases or be specified?)


>  > In PEAK, there is a base schema that's intended to be used for creating
>  > event-driven applications (that use a Twisted reactor or PEAK's
>  > mini-reactor).  It defines some top-level parameters to control the
>  > application as a whole, and expects to have sections included that
>  > implement certain abstract types for event-driven components.
>
>Do you expect the "typical" extension to simply define (or import)
>concrete section types that correspond to the abstract types defined
>by the base schema?

For the specific situation listed, that's the minimum requirement, but I'd 
guess that sometimes people will want to add other top-level keys that are 
specific to their application, in which case they will also be redefining 
the datatype.


>If so, I'd be inclined to just use something like %import and let the
>application be defined by the set of extensions imported.

Yes, I think %import is much more convenient when the schema extender is 
simply adding on to the base application, and not creating a new app from 
the base app.  It will be a handy addition to ZConfig, certainly.


>  > I can definitely see the benefit of %import for using an existing
>  > application's schema, to extend the application with custom code.  But,
>  > that's not my use case, which is to allow extending the application 
> itself,
>  > thus creating a new application, which is then given to an end user to
>  > configure.
>
>That is a distinctly different case, and it makes sense to extend the
>schema for this.

Indeed.  I have at least one situation in which a proprietary application 
will extend a PEAK-supplied ZConfig schema to add its own types, but it 
would be inappropriate for that app to expect users to %import the 
proprietary application's data types in the configuration file(s).