After 7 years doing content management systems, I have no idea what "customized, performant retail content delivery system that is largely separate from the system used to enter the content" means, and I wonder if I ever have seen one. :-) I also have never before met anybody who defines CMS in that way, so I seriously doubt that's what people usually means.
Hmm, that's the way the market has seemed structured
Posted byzopepaulat
2008-02-06 06:26 AM
I believe the big boys have always rendered piles of HTML files to disk for static delivery. Here are some example links:
- Bake vs. Fried, http://www.cmswiki.com/tiki-index.php?page=baked
- Static vs. Dynamic, http://www.cmswiki.com/tiki-index.php?page=Static+versus+Dynamic+Publishing
- CMS Watch on content delivery, http://www.cmswatch.com/Trends/472-Content-management-and-delivery
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.
- Bake vs. Fried, http://www.cmswiki.com/tiki-index.php?page=baked
- Static vs. Dynamic, http://www.cmswiki.com/tiki-index.php?page=Static+versus+Dynamic+Publishing
- CMS Watch on content delivery, http://www.cmswatch.com/Trends/472-Content-management-and-delivery
- CMS Deployment Patterns, http://contenthere.blogspot.com/2007/06/cms-deployment-patterns.html
Replies to this comment
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.
Replies to this comment