[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

> it's not that big architectual change. everything else discussed is
> possible anyway. i would rather call it a feature than a design change
> (since the change happens anyway).

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.

> 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.

Better to leave that up to higher level frameworks to implement this type of
generality.

> 2 more properties on the fti (addforminterface, schemainterface), both
> are optional, but provide then the discussed and requested flexibility
> for different type implementations.

Optional properties still need to be maintained and may still create confusion
or conflicting assumptions. Here, we've invented two new concepts (the type has
a schema, the type has an interface that describes the add form). It may be that
more advanced frameworks need something a bit different, and so they'll have to
either overload or ignore those properties.

> if we do not consider this questions at this state, again the result
> will be stupid and ugly subclassing and incompatibility and bad readable
> code and overrides.zcml (which is one thing i really hate!).

I don't know if that's true. Trying to solve all problems at the most basic
level is probably not a good idea. Giving the right hooks probably is.

I think if we make the addview name used for the rendering of menus a TALES
expression, then the traverser thing becomes a CMFDefault implementation detail
(not even CMFCore).

Dexterity has its own FTI type. It will always need that, no matter how many
hooks you have here. I have no problem with that, actually - GenericSetup makes
it easy. Dexterity does not need any overrides.zcml either. ;-)

> right, therefor you always have the possibility to write your own form
> implementation.

I think it's a mark of bad framework design if that "possibility" really means
throwing away most of the conventions and standard support and building up
something else starting from a very low level. In that case, the framework's
tried to too much application-level work that ends up being useless to the
actual applications (like Plone), who then have to invent their own parallel
framework to support their own slightly divergent use cases.

> i simply wonder why people should write code for default behaviour when
> there can be a default implementation.

I don't think it's a safe assumption that *at the CMFCore level* we'll have a
sensible "default". It's a pretty big assumption that it's sensible for most
applications to have a linear form that uses formlib's default widgets with no
custom setup code for most types.

> i only want to point here to the plone portlets engine. why is it
> necessary to provide 4 (!) classes, a template and a zcml configuration
> for 1 portlet? thats imo too much, especially because people are
> familiar with and love the 'write-less-do-more' mentality, and adherence
> to a tradition is not automatically more productive or easier to
> understand.

I can tell you why it's necessary in another thread. It's irrelevant here (and
on this list).

Martin