[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