[Zope3-dev] schema initial documentation

[Phillip J. Eby]

At 05:35 PM 4/22/02 -0400, Jim Fulton wrote:
>"R. David Murray" wrote:
> >
> > On Mon, 22 Apr 2002, Godefroid Chapelle wrote:
> > > About extensibility, it should be easy to add properties necessary for
> > > other tasks - I refer to SQL generation you mentioned for example.
> >
> > Martijn and I had a long discussion about this a little bit ago
> > (http://irclogs.espnow.com/zope/show_file.php?logfile=2002_03_28.log,
> > search for '<faassen> rdmurray:", that's where the conversation starts)
> > in which we tentatively concluded that information like that belongs
> > in a separate object that is composed with the field, probably using
> > an adapter or perhaps specialized zcml.  We didn't try to work out
> > what this would look like, though.
>
>I like that idea.

For what it's worth, in TransWarp I use the Python 2.2 distinction between 
class and instance variables to do this.   For example, aPerson.arms 
returns the value of the 'arms' feature, but 'aPerson.__class__.arms' 
returns the Feature object itself, which provides metadata and methods.  In 
TransWarp, such metadata and methods may include SQL generation, UI 
rendering/marshalling code, database storage/retrieval, validation, 
etc.  Some of these methods may be "exported" to the instance, macro-style, 
others remain bound directly to the Feature and are only accessible by 
retrieving the Feature from the object's class.

If Z3 took this approach, I'm assuming that instead you'd probably go with 
a more declarative sort of Feature object and do the rest with adapters.

Of course, it may be that you don't even want to assume the existence of 
class attributes, and instead want some kind of metadata access method like 
"getFeatureDefinition()" on the instance.  But TransWarp would still 
interoperate with a trivial extension in that case.