Maybe I tried to express what I meant too succinctly, but as I understand common lingo, a "CMS" as a system that allows you to enter content using a UI designed for content editors *plus* a subsystem that allows that content to be displayed in a separate UI for more retaily users. It's typically true that the content editing UI is allowed to be stark and ugly, while the retail UI must be bright and shiny. Likewise, the content editing UI doesn't normally need to handle hundreds of requests per second, while the retail UI (for some customers, at least), does.
Plone does a good job at the content entry interface and can also customize the content entry interface in arbitrary ways, which is great. And Plone obviously does allow you to present a separate custom UI for retail, but often people's expectations about the ratio of how much time any Plone-based solution will take to develop and how it will perform is overoptimistic. Caching does solve some of this, but it's still a fairly complex thing to configure if performance is a major issue, and it takes time to get right.
There are also subtle interactions between editing and delivery. One thing people expect of a content management system is to be able to edit a copy of an already published document without unpublishing it, and without making their changes live after each save. Of course, if we used a baking model, this wouldn't be an issue at all, we'd just allow the editors to edit away, and push the big red button when they were done. This has its own set of hideous problems, obviously.
But Plone(3, at least) is fairly opinionated about how it should be done, for better or worse. We keep versions of content around in the ZODB. Sometimes, Zope->CMF->Plone->ZopeVersionControl->CMFEditions->Iterate is way too heavy a stack to allow for simple in-work copies of stuff, because it's just far too general, and god help you if it breaks. But since it's "the way to do working copies" in Plone 3, wary consultants are usually defending a proposal to *not* use it against enthusiastic and optimistic (and wrong) end users. ;-)
In any case, whether or not we agree that Plone is a CMS, it probably doesn't matter, it's mostly besides the point. Picking on the term "CMS" was a convenient example of marketing overrunning truth to me, but maybe we can agree to disagree. The point was just that Plone isn't fit for every purpose, but people want it to be that. And that leads to a reality distortion field that bleeds over into customer beliefs. Perhaps this doesn't bother other folks, but I quit my job in 1999 largely because I was made to use something that wasn't fit for purpose at all (Zope *was* the right solution, MS Site Server wasn't), and I get deja vu a lot of times when approached with Plone-as-a-solution-in-hand for an arbitrary problem.
tangent about CMFEditions and folderish content
Posted byslinkpat
2008-02-06 10:08 PM
For god's sake, please nobody repeat the mistake we at openplans.org made: implementing the historical revisions feature by combining CMFEditions with RichDocument (or anything else folderish). Why? You end up with a complete pickled copy of the folderish page and all its content (in this case, uploaded attachments) for *each* revision. This makes our history views insanely expensive. Now we have to dig ourselves out of that hole.
Plone does a good job at the content entry interface and can also customize the content entry interface in arbitrary ways, which is great. And Plone obviously does allow you to present a separate custom UI for retail, but often people's expectations about the ratio of how much time any Plone-based solution will take to develop and how it will perform is overoptimistic. Caching does solve some of this, but it's still a fairly complex thing to configure if performance is a major issue, and it takes time to get right.
There are also subtle interactions between editing and delivery. One thing people expect of a content management system is to be able to edit a copy of an already published document without unpublishing it, and without making their changes live after each save. Of course, if we used a baking model, this wouldn't be an issue at all, we'd just allow the editors to edit away, and push the big red button when they were done. This has its own set of hideous problems, obviously.
But Plone(3, at least) is fairly opinionated about how it should be done, for better or worse. We keep versions of content around in the ZODB. Sometimes, Zope->CMF->Plone->ZopeVersionControl->CMFEditions->Iterate is way too heavy a stack to allow for simple in-work copies of stuff, because it's just far too general, and god help you if it breaks. But since it's "the way to do working copies" in Plone 3, wary consultants are usually defending a proposal to *not* use it against enthusiastic and optimistic (and wrong) end users. ;-)
In any case, whether or not we agree that Plone is a CMS, it probably doesn't matter, it's mostly besides the point. Picking on the term "CMS" was a convenient example of marketing overrunning truth to me, but maybe we can agree to disagree. The point was just that Plone isn't fit for every purpose, but people want it to be that. And that leads to a reality distortion field that bleeds over into customer beliefs. Perhaps this doesn't bother other folks, but I quit my job in 1999 largely because I was made to use something that wasn't fit for purpose at all (Zope *was* the right solution, MS Site Server wasn't), and I get deja vu a lot of times when approached with Plone-as-a-solution-in-hand for an arbitrary problem.