While that could change, it's not likely to happen in the next 2 years or so.
The Good
Plone was/is(?) very innovative in the area of Content Management and Web Applications development. It could possibly be the most advanced Content Management System on the market today. The technologies made accessible through/with Plone are amazing and it helps you build powerful multifaceted sites and applications with relative ease.
The Bad
The stack is probably the biggest stumbling block for building applications in Plone. When I'd decided to build a site with Plone (back in 2002), I thought it would be pretty straight forward to get up and running. It was. I thought it would be relatively easy to maintain. It was. I thought upgrading would be a little tricky but easily palatable. It wasn't. Some where around Plone 2.1 they had switched from using "Zope Native" content types to something called "Archetypes" which was supposed to be more flexible and make it easier to build your own custom content types and therefore your own applications. I should have seen the writing on the wall at this point but I was blinded by enthusiasm and ambition.
Plone is an application built on Zope CMF. Zope CMF is a Content Management Framework that runs on the Zope Application Server. The Zope Application Server is written in a combination of Python (for flexibility and rapid development) and C (for optimization and speed).
One of the first problems I'd come across was migrating all of my content from Zope "native" Content Types to Archetypes based Content Types. Then updating/porting my programs to do the same. This was an annoyance at the time but I figured it was well worth the headache as it was making me more familiar with the underlying technologies. My Python hacking was getting better, I'd picked up a little JavaScript, and I could sort of understand the transactional database used to power the applications.
As time went on I got more and more confident in my Zope/Plone hacking abilities because I'd been working on my sites and applications. When I say "working on", I really mean "working on". Methods and functions were constantly being deprecated, if not by the Plone Core Dev. Team then by CMF or by Zope or possibly rearranged by the new version of Python. Between the 2.1 and 2.5 versions of Plone, I'd done no fewer than 12 updates to one application just to address deprecations. Then there's the fact that over the course of 4 years we'd gone from Zope Packages to Zope Applications, to Plone Applications, to Python Eggs as mechanisms for getting 3rd party software installed on a Plone based site.
The Ugly
Many things are changing which I believe could be a great thing in the long run. In the meantime it requires you to be diligent on a number of fronts. Zope Corp. has released Zope3 which has technologies that are being back-ported to Zope 2 (the version that Plone is built on). Those technologies are making their way into Plone and eventually Plone will/should/may run on Zope3. Python 3 is out. Zope may or may not support this new version of Python, which is not backward compatible with previous versions. All of this spells a bunch of heartache in trying to maintain applications written for Plone.
Hope
The community has been great. The list of people to whom I owe a great debt of gratitude for help on things from the minute to the momentous includes
- Andy McKay
- Mikko Ohtamaa
- Alex Clark
- Ross Patterson
- Alexander Limi
- Fabrizio Reale
- Steve & Donna (at csquaredtech.com)
- Lorenzo Musizza
That's just to name a few. There are really smart people with great ideas working on Plone. Development is moving at a very quick pace and I think it will get to a point where the product is once again the write solution for many problems. I eagerly await this day. Until the underlying stack is more stable and there are fewer new things that break older ones.. I'll be stearing clear.
No comments:
Post a Comment