Adam Groszer wrote:
> 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
- 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.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -