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

Christian Scholz cs at comlounge.net
Mon Jan 16 05:55:44 EST 2006


Hi!

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

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.

-- christian





More information about the Zope-CMF mailing list