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