[Zope-CMF] Re: Re: [Plone-developers] Re: Re: The components of Archetypes

[Martin Aspeli]

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  
does

  - 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?

Obviously I see some problems with all of those, but I'd like your  
opinions. :)

Martin


-- 
(muted)