proposal: Custom schema properties
Hello, Custom schema properties proposal ================================= The problem ------------ is that we have a "baseline" project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required. The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change. The solution ------------ would be to have default schema properties defined as "usual" (depending on the implementation the field object would come from a different package). Those defaults can be overridden by "Interface.fieldName" and site (by utility or adapter lookup). Seems like fields that are not overridden in the interface subclasses might not be overridden. Further goal could be to have these customizations easily modified TTW. That somehow suggest that an adapter registration for each property customization is a no-go. Performance Performance needs to be as close as possible to the plain schema implementation. I guess field properties get evaluated quite often per request, an adapter/utility lookup per property evaluation is a no-go. I'd say zope.schema classes should stay as they are, the custom schema will be done using subclasses. Dependencies If no additional dependencies will be added to zope.schema the implementation could go into zope.schema.custom if yes z3c.schema.custom could be the place. Opinions? Anyone suffering the same problems? Up to now this is just a draft, more checking and tinkering to be done at the ploneconf2009-ZTK sprint. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: They just buzzed and buzzed.....buzzed.
Hi Adam
Betreff: [Zope-dev] proposal: Custom schema properties
Hello,
Custom schema properties proposal =================================
The problem ------------ is that we have a "baseline" project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required.
The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change.
The solution ------------ would be to have default schema properties defined as "usual" (depending on the implementation the field object would come from a different package). Those defaults can be overridden by "Interface.fieldName" and site (by utility or adapter lookup). Seems like fields that are not overridden in the interface subclasses might not be overridden. Further goal could be to have these customizations easily modified TTW. That somehow suggest that an adapter registration for each property customization is a no-go.
Performance Performance needs to be as close as possible to the plain schema implementation. I guess field properties get evaluated quite often per request, an adapter/utility lookup per property evaluation is a no-go. I'd say zope.schema classes should stay as they are, the custom schema will be done using subclasses.
Dependencies If no additional dependencies will be added to zope.schema the implementation could go into zope.schema.custom if yes z3c.schema.custom could be the place.
Opinions? Anyone suffering the same problems?
If we implement a generic solution which allows to manipulate all field properties, we should probably add an option for mark customizable fields for define some minimal requirements e.g. min=2 can get overriden with min=1 but not with min=0 etc. We should also make sure that we can change a field default='foo' to default='bar' but not required=True to required=False etc. This probably means that we should have one or more customization properties for each existing field property. Based on the complexity of this implementation we should implement this concept as a z3c package. This package will probably also depend on other z3c.schema fields e.g. z3c.schema.email if we need to implement special customization properties for each field. Regards Roger Ineichen
On 10/25/09 15:08 , Adam GROSZER wrote:
Hello,
Custom schema properties proposal =================================
The problem ------------ is that we have a "baseline" project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required.
The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change.
Doesn't http://pypi.python.org/pypi/plone.behavior provide exactly that feature? I'm pretty sure we can get that BSD licensed if it's helpful. WIchert.
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. On Mon, Oct 26, 2009 at 10:45 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
On 10/25/09 15:08 , Adam GROSZER wrote:
Hello,
Custom schema properties proposal =================================
The problem ------------ is that we have a "baseline" project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required.
The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change.
Doesn't http://pypi.python.org/pypi/plone.behavior provide exactly that feature? I'm pretty sure we can get that BSD licensed if it's helpful.
WIchert.
_______________________________________________ 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 )
-- Best regards, Adam
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
participants (5)
-
Adam GROSZER -
Adam Groszer -
Martin Aspeli -
Roger Ineichen -
Wichert Akkerman