[Zope3-dev] schema initial documentation

Martijn Faassen faassen@vet.uu.nl
Sat, 20 Apr 2002 21:13:37 +0200


Phillip J. Eby wrote:
> At 01:26 AM 4/20/02 +0200, Martijn Faassen wrote:
> 
> >    Enough theory; how does one define a schema? Much like one would
> >    define an interface, but it has fields instead of methods::
> >
> >      from Interface import Schema
> >
> >      class IPerson(Schema):
> >          """A simple schema for a person.
> >          """
> >
> >          initials = StringField(
> >             title="Initials",
> >             description="Initials.",
> >             )
> 
> Why have a separate base for Schema?  Interfaces already support Attribute 
> objects, let's just make fields derive from Attribute or something similar.

Fields do derive from Attribute already in the Zope3-property-branch.

This is a good question. I've made Schema a special type of interface
because of a number of reasons, some better than others:

  * Jim seemed to have the idea you shouldn't mix fields with methods.
    So based on that, I figured we should have separate schema interfaces. :)
    But Jim should jump in and explain his thinking here.

  * If you know your schema only contains fields, and not methods, you can
    actually write code that *implements* the schema. You can't do that
    with ordinary methods. Schema contain enough information to actually
    create an object with the right attributes on the fly, however.

I also don't think there should be anything stopping you from extending
a schema with a 'subclass' interface that does add methods. Perhaps
that makes the whole point moot. The essential thing that we should take
care we can do is the automatic generation of objects (or classes)
that implement a schema.

> One thing that's rather interesting here; an opportunity for overlap with 
> Features in TransWarp...
> 
> In TransWarp, a "feature" is a class attribute that can export methods to 
> its containing class, possibly in addition to being a property of that 
> class' instances.
[snip]

Interesting. I'm not entirely sure I see the overlap with schema, however.
Do you mean to indicate a parallel between Field and Feature objects, in
that they're both rather 'intelligent' part of an interface (as opposed to
simple methods and attributes)?

Regards,

Martijn