Am Mittwoch, den 16.07.2008, 15:24 +0000 schrieb 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.
it was just a suggestion, so i have no problem if the fti does not know
about this, but still is imo a good place to store such an information. 

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

> 
> 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).
i know that it's necessary, i also know why. i took this as an example,
nevertheless i like the portlets engine.

anyway my opinion is even here it would not be that big challange to
provide default implementations.

plone 3+ is in it's design and code organized much better than plone
2.5-, but also harder to understand for newbees since someone needs much
more base knowledge to adopt it. imo this should be considered a little
more when improving things. to keep not always the simplicity at
framework side but rather in using it from the developers and
integrators pov which was much about the success of plone. but thats
beyond this thread.

robert

> 
> 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
-- 
Robert Niederreiter
IT-Architecture & Engineering
Aflingerstraße 7
A-6176 Völs
+43 699 160 20 192
+43 512 89 00 77

Squarewave Computing         WEB APPLICATIONS,  ZOPE,  PLONE, HOSTING
BlueDynamics Alliance        production: concept, development, design
http://squarewave.at         consulting: analysis, coaching, training
http://bluedynamics.com      management: projects, process, community


_______________________________________________
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

Reply via email to