sean.upton@uniontrib.com wrote:
My take on this...
Better yet, use the CMF and keep your "controller" and "view-assisting" logic in skins code, and your data/model related stuff in your Python Product classes.
In trying to explain the CMF's wide-not-deep approach to this to some people I work with, it has become clear to me that coding a Python product for the CMF (if nothing else than becuase of the skins tool) is much cleaner than trying to cram things like acquirable helper utility methods into a specialized folder class and other sorts of strange things, and living by the "logic in content types and tools, presentation and application code in skins" way of the CMF is really the easiest way to accomplish this. My CMF coding is much more compartmentalized and easier to read than the stuff from previous Zope projects I have worked on.
Sean
Sean, I also like the CMF ways esp. for the skins tool, but how do you handle the stuff coming with CMF you _don't_ want to use. Like the membertool, workflows, syndication etc. Do you have a custom CMF-site object, do you delete the autocreated objects you don't like after adding a stock CMF site? Also, how are you handling the fact that now your products now are "not in one piece", since methods are spread through the skins tool? I really wish the CMF wouldn't be effectively one big software BLOB. Any clever tricks to share? cheers, oliver