Custom schema properties proposal
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.
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 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.
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.
Adam GROSZER mailto:agros...@gmail.com
Quote of the day:
They just buzzed and buzzed.....buzzed.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -