[Zope3-dev] TTW Schema-based content types

[Jim Fulton]

Sidnei da Silva wrote:
> On Mon, Aug 04, 2003 at 12:01:46PM -0400, Jim Fulton wrote:
> | Sidnea threatened to start working on "ttw schema". I'm note sure
> | exactly what he means, but I thought I should write down some of my thoughts
> | on the matter.
> 
> Just for the records what I want is exactly what you stated.
> 
> So, putting stuff together:
> 
> | Here's what *I* want. I want people to be able to create schemas in
> | site-management folders.  There should be a nice GUI UI for
> | this. (Note that you can create schemas in persistent modules TTW
> | now. Of course, there's no UI.) These schemas should register
> | themselves with the schema service.
> 
> We currently don't differentiate schemas from interfaces, and we have
> a interface service, so it seems that we need a 'local'
> (a.k.a. persistent) interface service.

Yes

> | The schema building UI needs to know about available fields. I can
> | see a couple of ways to approach this. There could be a field
> | service, or, perhaps, the factory service could be used.  Maybe the
> | builder should ask the factory service for factories that create
> | IField objects. This will require enehancements to the factory
> | service though.
> 
> I like the idea of doing this with the factory service. I had the need
> of doing something extremely similar to this and ended up not doing it
> because I thought it was specific to my app. So, I propose changing
> the IFactoryService to have the following:
> 
>   def getFactoriesFor(iface):
>     """ Return a list of factories that creates object which implement
>     the given interface """
> 
> Looks good?

Yes, although the doc string isn't formatted correctly. :)

> | Once we have a schema, it should be easy to create a content type
> | based on the schema.  There should be a class with __getattr__,
> | __setattr__ and __delattr__ that uses the schema to provide data
> | management.  I suggest that these TTW schema should have the
> | property that each field should have a unique id.  The content class
> | should use the ids, rather than the field names to manage data.
> | That way, fields can be renamed without messing up existing
> | instances.
> 
> Ok, I had some trouble figuring out where this would take me, but I
> think I see it now. I think that when we have a TTW Schema registered
> with the interface service, the next step for creating a content
> object is registering a factory for our TTW Schema. This factory could
> also use a 'mixin' class of choice or other fancy stuff one would want
> plus the class Jim suggested (with custom __**attr__) and generate a
> content object. We can also need to provide an additional list of
> interfaces this object will implement.

I wouldn't use a mix-in class. I'd just use a single class to implement
the factory that uses the interface on an instances. IOW, I would not
generate a class for the schema.

> The third important thing is assigning security permissions to the TTW
> Schema. Stephan Richter says that he has code for that in the workflow
> package.

Hm. Good point.

> The fourth important thing is registering views for our TTW
> Schema. AFAICT, the current machinery is already able to do this,
> provided that we have the interface in place. (We have a local view
> service, dont we?)

Yup.

> Is there something else missing here?
> 
> Now to the next level (or back to the black board):
> 
> For generating the so called TTW Schema, there is some stuff in place
> under the schemagen package, that Steve and Faassen wrote up back in
> December. No one seems to be using it, AFAICT, but it looks like we
> can get very close to what we want by starting from there. Any objections?

I didn't think schemagen actually had a schema editing UI.  I think the emphasis
in schemagen is to generate classes, and maybe schema in persistent modules.
IOW, it generates code.  This was driven by the fact that persistent classes
must be in modules. Schemas need not have this limitation. And if you don't generate
a class, there's no class code to put in a module.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org