[Product-Developers] Re: How can we win the battle for developers?

Michael Hierweck team at edv-serviceteam.net
Fri May 9 07:32:31 UTC 2008

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

* 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.


More information about the Product-Developers mailing list