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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
