[Framework-Team] Our attititude to Archetypes

[Martin Aspeli]

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