Hi everybody, I would like to tell my personal impressions of Plone from a somehow experienced programmer.
Well, my first contact with Python some years was a the university of Dortmund, when we discussed different types of programming languages and consider which languages could be used at schools as introduction to computer science. So when I started to look a Plone a already had an impression of Python but no real project or programming experience. Before starting developing internet portals using Plone I often used Typo3 (which I would consider as broken by design - the Typo3 folks are doing a complete rewrite now) and some other systems. I was looking for better designed and more powerful plattform and had a look a Zope because my favourite web hoster did not support J2EE/JEE that time. Well, pure Zope2 (2.7 at that time) was not what I was looking for, but Plone (2.1) was. (--> For acquiring developers we need more (managed) hosting services as developers often don't want to work a system integrators/admins.) And so I starting playing around and go disappointed for the first time since Plone appeared to my as a huge mix of Python scripts, filesystem scripts and page templates calling each other and giant underlying "magic" libraries CMF, OFS and some more. Andy McKays book which I read about three times was helpful to get do know what an editor or customizer needs to know, but did not really explain how the system internally was designed or worked. There was lots a boilerplate code, especially for creating new portal types that I could copy and paste - but did not understand. Python as easy to read language is not helpful either when it's frequently calling unknown functions or methods. Using the source or a debugger does not help either when you lack any orientation in the source files. (--> We need up to date documentation explaining the systems architecture from a brief overview to detail.) A short time later my local volleyball club asked if I could renew their website. Plone seems to hit all requirements, we would need some new portal types, a slightly modified workflow, some portlets and a skin. (You would be able to solve this after reading Martin's book nowadays). That time Robert Rottermann (from redCOR) invited my to join two trainings and after that I successfully created my first Plone Site. Thank you, Robert. (--> We should encourage newbies to join trainings. Trainings should cover the systems architecture) The time went by and Plone 2.5 appeared. ZCML was simply a shock. Some days before a was faced with and awful configuration error for the first time I had watched some of Sean Kelly's screen casts about Plone and what he called a headache. (You know the video comparing Zope/Plone with JEE, Rails and Django?) Zero lines of code, no configuration files - Plone how did you regress? (That was my impression that time.) I updated several Plone Site I had build in the meantime and treted ZCML just as additional boiler plate code. Most of the tutorials out there did not really explain "why" but only "what" to do. Martin's borg tutorial many people referred to was to complex to me. (Well, I think component architecture can't be understand by reading two or three pages. I takes time to think about it, rethink about and some time you'll get deeper insight.) (--> Don't really know what could be improved here.) That time I maybe had dropped Plone. But I worked as team member for the user interfaces of a medium sized JEE project using JSF and Facelets and realized: JEE is even worse. The trouble is nearly the same but there more headaches and it takes longer to solve them. Back to Plone: To give Plone a chance I bought Philips book and started to read. This helped my to understand component architecture and the new redirection of Plone development. I also ordered Martin's book (what was not easy that time in Germany). Both are great literature - what's massing: Martin gives overview of Plone and a well explained introduction into the most common design patterns and aspects of site developers. Philipp gives deeper insight into Zope 3 and the component archticture. (Thank you, both, for taking the time and sharing your knowledge.) But Plone depends on Zope2 and I did not find documentation about the Plone architecure, CMF, OFS and the things below. Why are "the things below" important for developers and customizers? When starting to do more complex things as skinning and simple schema based ATs you will need to use the debugger some time. Or you will probably sooner or later get into performance problems and need to profile. "Profile" or "use the debugger" appears often as hint on the mailing lists. No doubt - these hints sound unkindly but they are true: as each site is different and each deployments has its own bottlenecks you need to get to know these tools. But debugging or profiling sessions often end up in code some where in the underlying levels. (--> We need more documentation of the underlying architecture to help developers to understand what's going on.) It's hard for me to study all those new technologies and design patterns. There too many concurrent technologies out now: * archetypes and their fields and widgets, Zope 3 forms using different fields and widgets, CMF Form Controller - three technologies to manage (different kind) of forms (*) * Zope 2 skins vs. Zope 3 themes (*) How to explain a customer that you have to use different widgets (example: ATReferenceBrowser vs. Uber(Multi)SelectionWidget) in edit and search forms? How to explain a newbie developer without leaving the mark of a overcomplex, not well designed system full of brownfields and even without a clear roadmap to consolidate these techologies? Just to get it clear: I like Plone. My favourite points to improve Plone and make it more attractive to delevopers: * More documentation of the underlying technologies * Strict roadmap to consolidate technologies and to get rid of brownfields (e.g. Archetypes, Zope 2 skins and (restricted) Python Scripts must die and be replaced by Zope 3 technologies. There should be one technology for defining forms only whether the data is persistent or not. Persistence is not about forms (views) but about model and maybe controllers. This affects input validation in the same sense, too.) * Improve performance and Plone/Zope's resource consumption to make it more attactive on small/medium sized projects as hardly developer will start with a large project. Thanks for your attention and please remember this was a intentional subjective report. Michael _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
