[Zope3-dev] IMPORTANT RFS: Through the Web Site Development

Steve Alexander steve@cat-box.net
Wed, 15 Jan 2003 18:12:31 +0200


 >Jim Fulton wrote:
>We could certainly provide a tool like this.  Steve and Martijn
>are working on a system for generating content types from schema.
>
>Their system generates Python modules that implement the schema.

Eric Roby wrote:
 >
> I would like to inquire about the status of this effort.

There is code in src/zope/app/schemagen.

This code manages the specification of evolving schema, and creates the 
python code for a module that contains the schema, and a class 
implementing the schema.

The class contains code to correctly manage evolving the schema over 
time, even when there are pre-existing instances of that class. For 
example, you can add, remove or rename fields in the schema. The data in 
instances is handled correctly without the need to find every instance, 
and update it. Although, that is also an option.

(From here down is science-fiction, but it is feasible science-fiction, 
and I intend to make it real before a Zope 3 beta release.)

You can use the standard local views / configurations / adapters 
machinery of Zope 3 to apply the kind of views you want to your schema 
classes, and to make security requirements for reading or writing 
attributes of the instances.

By default, all instances of the schema class are registered with the 
HubIds service, and they are tracked and indexed in an index that is 
associated with the schema manager. So, you can ask how many and where 
the instances of this schema are. Of course, you'll be able to disable 
this indexing if you don't need it.

The code that is generated is put into a TTW module, and can be used as 
the basis of a normal filesystem class or a persistentent module class. 
So, there's a straightforward migration route from a TTW generated 
schema to a persistent product or a filesystem product.

There will be some facility for mixing-in base classes for extra methods 
with your own code in, or perhaps of just mixing in the text of some 
python methods.


I have a bunch of notes on where Martijn and I planned to go with this. 
I'll try to find the time to write them up somewhere public, or get them 
checked into CVS. Ultimately, I envisage a drag+drop interface for 
assembling fields into a schema, and setting default values and 
constraints etc.

So, think of it like simple ZClasses, except that they can be evolved 
painlessly, and there's a straightforward migration path to "proper 
programming".


The director of Codeworks sees this as an important project for zope 3, 
so Albert from Codeworks has some time to work with me on getting this 
finished. I hope we'll be working on this within the next few weeks, but 
  that depends how much time time I can spare from my paying day-job.

My immediate Zope 3 work is on the local utilities service, and the 
query service. Those are more urgent for Zope 3 development than schema 
generation, so I'll be working on those first.


> We have built a generator (don't know what else to call it) that takes a domain ontology

An "ontology" in this sense is a semantic network that describes the 
domain, right?

> (currently an RDF Schema) and builds a zope product from it. Obviously this ontology is
> limited to defining a data model, but we are trying to devise a way to define/model
> application ontologies that would provide a means to build controller and view
> components.

Cool.

> I am trying (as much as possible) to follow the discussions going on in this
> listing so that what we end up with is a process that will fold into the 3 architecture.

You may be able to map your RDF schema onto a number of related 
managed/generated schemas, as described above.

Do your ontologies evolve over time?

--
Steve Alexander