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

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to