Hi guys, I read interesting PLIPs like http://plone.org/products/plone/roadmap/138 and suggestions on the lists and code in the Collective, all of which rely on Archetypes to implement various functionality that perhaps isn't "base" content, but rather "meta" content like per-user annotations or ontology/category concepts.
During the 2.1 release cycle I got spanked by Stefan for putting an import from Products.Archetypes into CMFPlone. I learnt to appreciate that principle: Plone shouldn't have direct dependencies on AT. This is mostly just about forcing us to define proper APIs and interfaces, but also about making it easier to rely on alternative implementations. I still have hopes for CMF to embrace Zope 3 schema-based content tyes more fully, so that we have a lighter alternative to AT. The problem is that the outside world (i.e. product authors) don't quite have the same purist view. Things like CMFEditions has "auto-versioning for all AT content types". LinguaPlone "works for all AT content types". Marshall "works for all AT content types". In a way it feels unclean and a bit dangerous if our goal is to lighten up or even move away from Archetypes. However, it's also a good thing. AT is an insulation layer. It's ubiquitous and unifies the API to content types. Most things that rely on AT rely on (a) references and (b) the schema (LinguaPlone also hacks ClassGen, which is a bigger problem, but the LP ITranslatable interface should be implementable in other scenarios too). We can (and should) externalise the reference implementation to not be tied to AT. The schema is very simple - lightweight (well, to the end developer at least) objects that define fields and widgets. I think we need to decide where to draw the line, though. Is "from Products.Archetypes" forbidden in CMFPlone? Should we encourage alternative patterns that are abstract from AT? Should we ship with products that only work on AT content types? I also think we need to think about how far we want to go with extending AT. One thing I've raised already is to make the schema of a content type more adaptive. I see a lot of supposedly hard problems that would be easy if we had some way of forcing users to fill in certain metadata based on site-wide policies or policies imposed by third party products, if nothing else. This would likely also need some markers to say "this is real content" vs. "this is meta-content and thus doesn't need specific metadata" But if we build this into AT, as opposed to using some additional UI paradigm in Plone than base_edit, this will (a) solidify the dependency on AT as the main/only way of creating content types and (b) involve a careful adjustment of AT patterns and code. Martin _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team