This article introduces the open source CMS called Plone. There is a discussion of the relationship between Plone and other web frameworks as presented in an online video by Sean Kelly. This post tries to verify the claims made in the video about both the extreme ease of development in Plone and about the advantages of scripting languages for user interfaces in general. An alternative comparison is presented briefly discussing a number of other popular open source CMS frameworks. The article concludes with a general explanation how you can translate the considerations from this article into a completely different and possibly unrelated consideration of your own. Or, more accurately, it caricaturizes the wrong way of making decisions, with a wink to the video.
Discovering Plone
Plone first caught my attention when I was investigating alternatives for Ruby on Rails and I watched the Better Web App Development video by Sean Kelly. The video presents sort of a contest between the classic J2EE framework, a couple of Rails clones and Plone. The video presents Plone as one of the best performers in the contest but somehow this wasn't enough to convince me at that point. I dismissed Plone and preferred Rails and TurboGears as a new generation of agile web frameworks.
A few months later I was searching the internet for a simple content management solution to replace Joomla. Not a bad word about Joomla here. It's a great piece of software written in a not so great language. PHP is not my favorite. With most simple CMS software written in PHP, any viable alternative based on Python is likely to catch my full attention.
At the time I was searching, I had forgotten about Plone from the web app video. When I saw the name, I did not immediately recognize it, but it did ring a bell. The front page on plone.org impressed me, but still I didn't connect the name to the Better Web App video before I started watching the Plone screencasts, not coincidentally also by Sean Kelly.
On my second encounter with Plone, I did not dismiss the software at all. On the contrary, I thought it was the most brilliant CMS innovation I had seen in years. I liked the internationalization, the W3C standards compliance, the wide availability of plugins, the user-friendliness, the matureness, the development activity and most of all I liked the choice for Python as the implementation language.
While recognizing the strengths of Plone, I still did not consider Plone as a competitor for Ruby on Rails or TurboGears. Those are meant for completely different purposes. The things you can do in Rails with ease, require a lot of effort in Plone. At the same time, Plone comes with a rich set of CMS-features out of the box, far too specific for the more general-purpose Rails framework. There are CMSs available based on Rails, but they don't fall in the same category. If all you need is simplicity and a powerful platform, they might work for you. If you're looking for many ready-to-use features and a pluggable architecture, there is no reasonable Rails-based alternative to Plone right now. I have good hope this will change over time and there already are some developments with this potential.
Plone and the video
Over the past few weeks, I started thinking about the video. I asked myself whether Plone actually belongs in the better-web-app-video or whether it was accidentally mixed up in the wrong contest. And I quickly realized there is no easy answer to this question. Your answer to this question depends on your point of view when you're watching the video. Your point of view is likely to be different from mine and it is likely to change over time when you're working on different projects.
Right now, I can think of roughly three perspectives to watch the video:
1. Choosing a buzzword-compliant full-stack web development framework (a Rails clone)
2. Choosing a ready-to-use platform for content management minimizing the time spent on development
3. Learning about the advantages of powerful dynamic scripting languages when developing rich graphical user interfaces focusing on usability
Up until now, I only considered the first two perspectives. With just those two perspectives in mind, the choice for the combination of Plone and the other frameworks in the video might raise some questions. In this case, the only logical explanation is Sean Kelly borrowing the Rails-hype as a clever way to promote his favorite project called Plone.
Maybe he does, but it is more likely that Sean Kelly has a legitimate reason for presenting Plone alongside the Rails clones when considering the third perspective. I had to watch the video for a second and third time before I realized his focus on the advantages of scripting languages for developing friendly highly customized user interfaces evolving from customer feedback.
Depending on your opinion, you might say Plone is more mature than the other frameworks or you might think Plone is a bit old-fashioned in comparison to the latest hypes. The video claims extreme ease of development for Plone. Some sources on the internet mention a steep learning curve.
The truth is somewhere in the middle and depends on your background. You need some basic knowledge of the machinery before you can do something useful. Experience with other CMS software will help you understand how this machinery is a well-considered solution guiding you away from many practical issues and helping you create modular and pluggable solutions.
For more advanced usage of Plone, you need to learn about the underlying Zope framework. Zope offers a lot more power than you're actually asking for and may overwhelm you with things that aren't immediately relevant to you. This complexity is compensated for by the wide availability of ready-to-use and free plugins for any purpose you can think of. These plugins are non-intrusive, easily customizable and very powerful. The architecture allows more experienced developers to package any customization as a plugin by itself making your own software as flexible and reusable as the framework itself.
But no matter how pluggable and flexible, I keep having ambivalent feelings about some claims made in the video. The video says Plone requires zero lines of code for creating a time logging application and it claims that zero lines of code means you can't make development mistakes.
I found out that even without writing code, there is still room for errors. If not in code, then there must be an alternative way to specify a model like a point-and-click interface. Even if you do manage to point-and-click your way through an UML modeling tool without making errors, then there still are configuration details offering room for failure. It's an innovative approach with unique advantages over coding, but it just isn't as easy as the video claims.
Initially, this was not what scared me away though. I think the creation of the first Hello-World example gave the wrong impression. I still think it is a bit strange that "hello world" takes so much effort if a complete interactive application is possible without a single line of code.
I know there is a good explanation best summarized with the keyword "Zope". The video didn't clearly choose between plain vanilla Zope (for hello world) and full featured Plone (for the time logging app). As mentioned earlier, Zope is so powerful that it may seem scary if you haven't seen it before. If you search the web, you may encounter some criticism of Zope, being overly complicated, unpythonic, old-fashioned or complete overkill. But you'll also find counter-arguments explaining Zope has been ahead of time for years and it is catching up with the latest pythonic insights in Zope 3, which was built from scratch to combine new insights and lessons learned from current flaws with all the successful aspects of the existing framework. A more incremental approach is "Five" (Zope 2 + 3) backporting Zope 3 improvements to the existing software which includes the latest stable release of Plone (2.5).
You may still criticize Zope 3, but I'd rather say: Zope is an acquired taste as a web framework, and the Plone CMS is the reward you get for learning Zope.
Zope doesn't compete with Rails; just like in many sports the heavy-weights champion does not compete with the light-weight champion. For most home-grown applications, a light-weight framework is recommended. But the Plone CMS is the living proof that a heavy-weight solution may be the most robust foundation for ready-to-use solutions on a larger scale.
Real world usage
From my recent experience working on a Plone web site, I learned that Sean Kelly is right about the advantages of scripting languages for developing highly-customized user interfaces. The only times I needed to restart Zope, was after the installation of new plugins. During development, every other change was visible instantly. And in contrast to my experience with other environments, I was never afraid of breaking the system or making errors I couldn't quickly correct.
Custom changes are always completely separate from the original code. An undo-tab allows you to revert to older versions. The very limited costs of testing even the smallest changes encourages you to get constant feedback for every step in the development process. Basic errors in typing or formatting result in descriptive error messages often pointing out the exact line and position of the failure in the code.
The extremely modular approach for separating partial templates, style sheets and scripts is puzzling for anyone new to Plone regardless of technical skills. The locations of the snippets are not intuitive but do turn out to follow logical rules after getting familiar with the details. A few hours of playing around is enough to recognize how all these separated snippets relate to each other as parts of a very clever solution with unique potential to be both flexible and pluggable.
After my first steps in Plone, there are some things I should further look in to. If they turn out to be worth discussing, they may be covered in future posts:
- Packaging the current customizations as a plugin product
- Creating my own plugin with custom item types
- Using the object oriented nature of the backend for very flexible and powerful behavior described by larger class diagrams
Back to the video
I agree with Sean Kelly that script languages are the preferred technique for creating and customizing graphical user interfaces for both client side applications and web based solutions. To be safe, I would like to add that some script languages are more appropriate and powerful than others.
Without having investigated every scripting language available, I think it is safe to say that both Python and Ruby in particular are outstanding for this purpose. As a result of the power of these languages, I'd say modern development frameworks based on Ruby or Python have a tendency to be even more outstanding as long as they are used for the exact purpose each framework is specifically designed for.
Comparing web frameworks shouldn't be about winning or losing in general. It should be about finding the most precise and clear definition of the problem at hand and investigating which framework is best suited to solve that problem. This explains why Plone is only appealing when you're searching for a CMS and why it seems a bit odd when you're solving any other problem. This is also why Sean Kelly starts with a specification of his requirements - which are likely to be different from yours and mine.
Comparing open source CMS software
When you intend to make a contest comparing Plone to its alternatives, it would make more sense to investigate open source CMS software instead of general purpose web frameworks. There are well known CMS solutions with a large audience and an active developing community. To mention a few, I think some reasonable alternatives to Plone are Joomla, Drupal and Alfresco.
Each of those has its own set of unique selling points in many regards, ranging from functionality to server limitations and from target audience to standards compliance. A full objective comparison is way beyond the scope of this article.
In order to make a point and without pretending to present proper research, what follows is an extremely subjective and narrow-minded comparison under the unrealistic assumption that the underlying technique is important enough to reduce every other aspect to a trivial side remark or less.
Being a software developer being naive and forgetting about the social aspects of software, I (falsely) assume the technical quality attributes make all the difference and with the right choice of technique my development efforts are stimulated enough to make up for lacking functionality.
From this technical perspective, I appreciate elegance in the design, aesthetics in the code, maintainability and flexibility of the framework, fault-tolerance, automated testing, standards compliance and a relatively high level of skills found in the community behind the product.
These are still way too many factors to consider in this brief discussion. For the sake of argument, let's assume there is a single discriminating factor implicitly covering for all these other factors.
Let's assume the implementation language is the single all-explaining discriminating factor when choosing a CMS. This helps us oversimplifying our comparison between Joomla, Drupal, Alfresco and Plone as a comparison between PHP, Java and Python.
Under all these assumptions, I can present some equally narrow-minded and prejudicial claims for each language. And please don't flame me for these, the undertone should be more than clear by now:
- A poor and error prone scripting language with a large audience of hobby users (PHP; Joomla and Drupal)
- A powerful but inflexible and time-consuming programming language whose main strength is found in larger enterprise application backends (Java; Alfresco)
- A mature and powerful agile object oriented scripting language best appreciated by the most innovative happy few of developers on this planet, who were responsible for some of the most ground-breaking improvements over the past few years, for example: GMail, the GMailFS hack, Blogger, the first Podcasting software, BitTorrent and SpamBayes (Python; Plone)
We can further summarize these claims to the following generalizations; without even the smallest piece of supporting evidence or credible source other than a vivid imagination:
- Me-too-software (PHP)
- (Over)regulation-is-strength-software (Java)
- Pragmatism-and-elegance-don't-necessarily-bite-each-other (Python)
The other contestants are no match for Python. It's sad there was no Ruby CMS offering some tough resistance. This means Plone is the winner on all my strict criteria and Alfresco is the runner-up that may prove to be valuable in large enterprise settings. Both Drupal and Joomla share a third place being the environment of choice for hobby usage or low-budget websites.
This last paragraph wasn't completely nonsensical, or was it?
As crappy as it is, this unfair comparison is no more and no less than a caricaturization of the unfair comparison in the video by Sean Kelly. And even though that comparison is unfair on the contestants, the video is still making some valid points in general.
Concluding
Rather than recommending Plone, I recommend thorough investigation of both problems and solution alternatives. Rather than selling my own preferences, I'd like to show an alternative view on things and let you decide for yourself based on your specific situation. There are numerous aspects way beyond this article that may outweigh any of the arguments made in this post.
Choosing Plone means you should value the specific power of Plone enough to be willing to accept the learning curve. I can imagine that a majority of people prefers quick gains on the short run over more abstract qualities on the long run.
In my opinion, Plone is an acquired taste.
And so are both Python and Zope in many ways. Like any other acquired taste, there is a small number of fanatic people who completely adore it and are willing to make major sacrifices in order to get the product of their preference. At the same time a majority of other people doesn't recognize the difference between an outstanding product and a cheap surrogate. In many cases, they might even prefer the surrogate because all the convenience stores are offering it off the shelve.
Having an acquired taste, it's easy to fool yourself into feeling superior and you might be too arrogant to see that your elite toy is not the ultimate answer to all your problems. There is no such thing as a silver bullet and there never will be. Put the focus on the problem before you focus on a potential solution and consider all alternatives, including the ones you disapprove of.
And if you happen to be in the fortunate position you're selecting an open source CMS, you have a proper technical background, enough time before the deadline and a dedicated web server of your own... Then take a look at Plone and decide for yourself whether it suits your needs.
N.B. If you haven't seen it yet, please take a look at the Better Web App Development video by Sean Kelly I mentioned in the first paragraph. Or watch it for a second time after reading this post.
Keep in mind some claims in the video are outdated. Agile frameworks evolve more quickly than anyone could update a video. For example, manual database creation in Rails has been replaced by automated pure-Ruby migration functionality for a long time now.
The general message in the video hasn't changed though. And I doubt it will any time soon.
Tags: Plone | Python | Zope