[Zope-CMF] Re: Add forms and menus
Charlie Clark
charlie at begeistert.org
Thu Jul 17 07:03:58 EDT 2008
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
More information about the Zope-CMF
mailing list