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 _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
