For example, if you need to add a dropdown menu in between your portal objects views, you have to add its caller to every one of its default-view methods: One portal type, one skin to be opened and modified. If you change your mind and find that your recently created menu is better at the bottom than in between the title and the cookedbody - for instance -, you need to peform the previous all over again. I call that repetitive, though not as a critic but as an invitation to think of a tool that solves this problem. Maybe it takes the form of a CMF skin, maybe just as an enhancement to the regular portal_skins tool. My vote is for the first alternative (as it's probable that the solution is code that writes code, while coexisting with previously installed skins.) Ausum ----- Original Message ----- From: "george donnelly" <list@zettai.net> To: "Ausum Studio" <ausum_studio@hotmail.com>; <zope@zope.org> Sent: Friday, September 27, 2002 3:08 PM Subject: Re: plone "vs." CMF was (Re: [Zope] What New Zope...)
Can you give me some more details on what you would like? What repetitive tasks are you referring to? (there are so many ;P)
<--> george donnelly - http://zettai.net/ - "We Love Newbies" :) Zope Hosting - Dynamic Website Design - Search Engine Promotion
From: "Ausum Studio" <ausum_studio@hotmail.com>
In my humble opinion there's still room for a new general-purpose CMF skin that takes over the repetitive tasks during the skin customization process, without the usual constraints that come as a result of being template-based. Something like a skin-control layer that allows developers to focus on features rather on just code, but powerful enough to allow every level of per-case customization, when needed.
I agree that Plone has suceeded at driving people's attention to CMF/Zope, but from a developer point of view I should tell, IMHO again, Plone neither can be opposed to CMF, neither Plone is CMF. :)