[Zope-dev] proposal: Custom schema properties

[Martin Aspeli]

Adam Groszer wrote:
> Hello,
> 
> After quickly glancing over plone.behavior it seems more like
> something to extend a schema, and does it solve the problem of "new
> properties -- new schema -- change everything around it"?
> 
> What I need is to be able to change schema properties per site. And
> skipping the need to fix the forms or whatever concerned with that
> changed schema.

I'm not sure I really understand your problem (from reading the original 
email), but I maybe offer a few suggestions.

plone.behavior is a way to create re-usable chunks of functionality. A 
behavior may or may not include a schema with form fields, and/or an 
adapter factory. When the behaviour is "enabled" for an instance (how it 
is enabled is application-specific: in Plone/Dexterity we list enabled 
behaviours against each content type), it will be possible to adapt an 
instance to the behaviour interface, and to look up the schema interface 
for form rendering, say.

There is also a package called plone.autoform, which provides a base 
class for z3c.form-type forms and enables schemata to be self-describing 
(e.g. "this field goes before that field", or "this field is only shown 
if the user has this permission"). plone.autoform interprets these 
"schema hints" to set up a suitable form.

Now, in Dexterity (a content type framework for Plone) we use 
plone.autoform in such a way that standard add/edit forms are 
constructed by looking at a type's canonical schema interface + the 
schema interfaces (if any) of any behaviours enabled on that type. This 
means that we can compose types from a number of behaviours (e.g. 
locking, versioning, staging, multi-lingual support etc) and other 
things fall into place: add/edit forms, views, viewlets and so on.

For your use case, I think the lessons are:

  - by using some kind of inversion of control on the forms and other 
schema-dependent things, you may be able to avoid the "re-register 
everything" problem

  - try to separate out the parts of the schema that are truly 
re-usable, and the ones that are application specific

  - register views/forms/whatever for the most generic schema feasible 
and ensure that this is provided by your instances

As for your specific proposal, I'd definitely keep it in a separate 
package: zope.schema needs to stay simple. We also need to be very 
careful about the possible side-effects of mutating schemata that may be 
used by other things. If the code you read (interfaces.py) is out of 
sync with the code that's executed, we end up with confusion.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book