A lot of the things that are CMF should have been put into Zope core.
Agreed, that'd been a lot better. The CMF is a framework. It'd be nicer if it'd been a set of independent components. Then Silva (for instance) could've used more of what's in the CMF than is possible now. In practice right now the picture is 'Use all of the CMF or none of it'.
DCWorkflow should have been there. acl_user folder should have been extended with property management and other member management instead of shimming tools and wrapping user objects as is done now. And even if portal_skins would have been included, they should have been empty of skins, instead of sending with a bunch of skins that makes CMF look like it almost is a finished product, when in fact, it just a bunch of handy tools.
Actually there's a version available of at least the filesystem to Zope part of the skins system, called FileSystemSite. This is the only part of the CMF that Silva actually uses, and a separate version had to be extracted and maintained. This is a good case in point that it should've been a separate system anyway.
Note that I actually also agree with Lennart that the whole concept of FileSystemSite (code on the filesystem, but actually in the ZODB) is rather odd. Silva on the medium term is switching over to a more advanced system that's purely filesystem code, more similar to Zope 3's view classes. Customization through the ZMI of skins is not possible anymore with such a system (unless some extra work is performed), but Silva never took that approach anyway so that's no loss to us.
But ah well, what is done is done. Too late to change the past now. :-0
Actually Silva is using this component approach more and more, though of course its core components besides Formulator are not used in many other projects. But in fact most of its foundation should be usable outside of Silva, though underdocumented.
We're in the process of factoring out more functionality though, and I expect this will slowly start to change. a few things that are going to happen in the few next months:
* A cache manager. Not very advanced, but mostly useful from a python persective for simple RAM caching but in a ZEO context. This is only for application level caches and doesn't integrate with Zope's built-in caching mechanism, but that's not the intent anyway.
* an extension manager; a Zope installation and configuration system that is inspired by Silva's system but is suitable for any Zope Product that needs to be extended through other Products. Silva is going to migrate to this soon.
* the new view system I spoke of. It'll be based on Zope 3 adapters. I've been talking about this for a while now, and it's still vaporware besides some protoypes, but a lot of preparation has been done and we're actually going to take the big transition to such a system over the coming months. Everybody else is also invited to us it. :)
Regards,
Martijn
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
