Martin Aspeli wrote:
> Hi Alec,
> I see that plone_schemas covers most of what I was asking about, which
> is great :)
> I took a look at plone_schemas' example type. I can't get it to install
> (Zope won't start, some conflict of versions, I'm sure), but looking at
> the code, I notice that you
> - Derive from PortalContent
> - Define an FTI dict
> - Define all the DC metadata accessors manually
> - Define a factory method
> - Manually construct an FTI etc. in Install.py
> None of that's rocket science, but I wonder if the framework shouldn't
> take care of some more of that. Part of the point would be to insulate
> your content types from changes in the underlying stack, e.g. if/when
> CMF stops using the portal_types/FTI constructs, for instance. If
> that's starting to sound like Archetypes, though, you're right. :)
> So... let's think about what we really *want*:
> - A simple Z3 schema in an interface that defines what my content type
> - A component-architecture compatible way of adding behaviour and
> other facets via adapters etc.
> - Something that works as a proper CMF and/or Plone (and/or CPS or
> whatever) type, that shows up in the add menu, that interacts with
> other Plone facilities.
> So - one problem is that there is a lot of Plone software out there
> that just assumes all content types are Archetypes. I'd rather not
> worry about that just yet, though, because we're not yet at the stage
> where we have a realistic general alternative, and with proper
> componentisation, fixing up those places where AT is assumed probably
> won't be too hard.
> But beyond that, CMF requires a lot of boilerplate, like above, that
> I'd rather not have to remember or deal with. So, what are the options?
> - Having the framework inject base classes and code based e.g. based
> on certain ZCML directives?
> - Using BaseContent or something similar as a base class?
> - Making a custom base class for plone_schemas-like content that pulls
> in whatever CMF needs, but insulates us from future changes?
What about code generation? At least for the FTI I would like that
because I see more explicitly what is used and I can change it myself
afterwards. Same might also be possible with other types of boilerplate.
The best way would be anyway to make the components in a way to be used
with any of the above solutions.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests