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
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
