[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