RE: [Zope] Basic, conceptual help / advice?
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 -----Original Message----- From: Andy McKay [mailto:andy@agmweb.ca] Sent: Wednesday, March 19, 2003 12:35 PM To: zoper@disturbance.dhs.org Cc: zope@zope.org Subject: Re: [Zope] Basic, conceptual help / advice?
Right now, I am implementing what needs to be a prototype in DTML, but it's already getting to be spaghetti, with UI and logic code all intermingled. I am leaning toward creating big external methods for the encapsulation that I need, but it just *seems like I am missing something*.
Write a Product and put all your logic there in Python, use DTML or ZPT to do your presentation. http://www.zope.org/Documentation/Books/ZDG/current/Products.stx will help. -- Andy McKay _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
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
First off, thanks to everyone that has replied - really helps. I've received some very good advice re: mapping my data tables to classes, and for better or worse am on the path of encapsulating much of my logic in external methods and pluggable brains. Regarding the suggestions to use CMF: My thoughts are right in line with Oliver's sentiments below: I ruled out CMF and (though it was a lesser consideration anyway) Plone because they contain far more stuff that I DON'T need or want then things that would be of help. I have no interest in wading through the process of learning the CMF during a project schedule just for the utility of the few things I would use. Learning ZPT is much higher on my list, and even that is deferred until I finish the project at hand (again, for better or for worse). Also, this is a functionality-heavy site I am working on, not a content-heavy one. I am using Zope as an application framework in this case rather than as a content management tool. I do wish that various CMF functions were available as individual products - that would be great. Thanks again for the advice, everybody, and keep it coming if there's more!
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.
zoper@disturbance.dhs.org wrote at 2003-3-20 09:09 -0800:
... Regarding the suggestions to use CMF: My thoughts are right in line with Oliver's sentiments below: I ruled out CMF and (though it was a lesser consideration anyway) Plone because they contain far more stuff that I DON'T need or want
Then use only what you want and need... We have CMF instances (lots of them) that use only ActionTool, SkinsTool, UrlTool, CatalogTool, PropertiesTool Some tools require others. Thus you are not completely independent. But, it is quite obvious how the tools are related. Dieter
Oliver Bleutgen wrote:
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?
You can easily reuse some of bits out of the CMF into component bits if you want. For example I wrote a product that just uses the skins component of CMFCore, so that when you add this folderish product, it adds a few skins in. The user can then skin the product as they see fit. It worked out pretty well and didnt take long to write. -- Andy McKay
participants (5)
-
Andy McKay -
Dieter Maurer -
Oliver Bleutgen -
sean.upton＠uniontrib.com -
zoper＠disturbance.dhs.org