[Framework-Team] Our attititude to Archetypes
optilude at gmx.net
Tue Apr 11 11:40:45 UTC 2006
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
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.
More information about the Framework-Team