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
schema" of the type. It's not necessarily a *bad* idea (at least I
so, since this is basically how Dexterity works :-), but right now,
have any notion of a schema. With this change, you're effectively
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
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
be considered to be generic.
I'm just not sure that generic is so good. If it's easy to make add-
views (probably with convenience classes for CMFish container adding
and obvious how to register them, then do you need more framework?
At least not
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. ;-)
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests