Am 16.07.2008 um 17:24 schrieb Martin Aspeli:

I think it's a fairly big shift to assume that the FTI has knowledge of "the schema" of the type. It's not necessarily a *bad* idea (at least I don't think so, since this is basically how Dexterity works :-), but right now, FTI doesn't have any notion of a schema. With this change, you're effectively dictating (or strongly suggesting) that all CMF types have "a schema" and that this is the basis for forms, and suggesting that forms aren't registered as independent
views but rather inferred from this schema.

Indeed. It is reasonable to expect a subclass to provide a set of FormFields but this is not the same as a schema. We have found being able to handle "portal_type" and "schema" or "fields" ie. an instance FormFields() in the super class to avoid repeated use of the somewhat cumbersome FormFields(TextLine(__name__...)) code.

we discuss the generic adding approach, we further discuss what has to
be considered to be generic.

I'm just not sure that generic is so good. If it's easy to make add- and edit- views (probably with convenience classes for CMFish container adding behavior) and obvious how to register them, then do you need more framework? At least not
in CMFCore.

Explicit is always better than implicit. This stuff really isn't a lot of work but it provides clarity and helps people understand what's going on and I think this is essential for any framework. Less magic is more power. ;-)

Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to