Full circle - Python web frameworks
A little over a year ago I got serious about doing web development
using Python. From what I have discovered, this is not exactly an easy
field to break into and understand without either guidance or a lot of
hard work. The first thing I had to do was choose a framework, and this
was during a time when the number of viable frameworks seemed to be on
the rise.
This is no longer the case.
Ultimately, I chose to use Plone and got some guidance from a Plone Bootcamp.
You may be thinking "Plone is a CMS, not a framework" and I'll get to
that in a minute. Recently, a project came up which presented the
opportunity to review my choice with greater insight and a bit of
experience. Also, a friend had just chosen to use CherryPy
for a new project he is undertaking. What should I use for my new
project? It's not exactly a website in the traditional sense. This will
be a special purpose web application, the way I thought about web
applications when I got started in all of this.
What is out there, available as open source, with enough of an
established base to allow me to successfully implement my project?
This list is longer than the one given in the article linked above,
but still justifiable. Each of these presents some interesting choices,
but the list can be reduced somewhat with a small amount of research
and expressing some preferences.
First off, I would rather reuse a quality component or mechanism than
do it myself from scratch. This means I'm after a full featured
framework rather than a DIY framework like CherryPy. Nothing wrong with
CherryPy, it just doesn't provide anything other than the extreme
basics - focus on processing requests. For example, CherryPy does not
use a templating system by default, allowing you to use whatever you
want. Now we have to evaluate templating systems. There is no default
database for persistence, etc etc
Interestingly, Turbogears uses CherryPy as its application server and
includes all of the 'best of breed' tools. The pieces have already been
assembled in a usable way, allowing you to get to developing your
application. Turbogears is considered a 'mega framework' because of
this. Pylons is similar in this respect in that it assembles various
tools that can be swapped out. Pylons uses the Paste application server
instead of CherryPy at its heart. Pylons has a Ruby on Rails style of
request handling.
CherryPy/Turbogears and Pylons can be reduced into one choice, keeping
in mind the preferences expressed, and because the next version of
Turbogears will actually not use CherrPy, but will instead run on top of Pylons!
The communities are combining and I think this is great. CherryPy
itself will probably continue to have a small hardcore following, but
lose the support of developers working on things like Turbogears.
Django seems like the odd one out with other communities folding into
each other. There is a great community around it and it has certainly
been put through its paces in the professional world. Again, the common
tools such as templating and persistence are in place. However, there
are a couple of things that Zope/Plone has over Django, in my opinion.
Not only that, but Django is very focused on the news / blog style of
application. I know it can be used to do just about anything, but it's
designed to make those kinds of applications easy.
Zope 3, Plone, and Grok all share a common Zope heritage in some way.
They all make use of the Zope Object Database, ZODB, for persistence
and use Zope Page Templates (ZPT). Plone is actually a Zope 2 CMS
product that can also use Zope 3 development techniques through a
project called Five (Zope 2 + Zope 3 = Five), which is now built in to
Zope 2.
Grok is being worked on to become "Zope 3 for the common caveman",
however, I am discovering that Grok is missing enough substance that
nearly any complex web application will need to dip down into its Zope
3 base to make it work. One only needs to consider user management to
see that Grok has a way to go to stand on its own. There's nothing
wrong with this, except that if you already know enough Zope 3 to get a
complex Grok application off the ground, you're probably already using
Zope 3.
Any reasonably mature framework based on Zope at this point is battle
tested and worthy of enterprise consideration. I'm a big fan of ZPT
because they render in a browser, making them easy to write. I'm also a
big fan of the ZODB because it is about the slickest persistence
available and I'm a programmer, not a system administrator. The ZODB is
often unfairly knocked on performance when in fact it is efficient, quite scalable thanks to ZEO, and able to handle heavy loads.
Zope, Django, and Pylons/Turbogears are all definitely worth
considering. Obviously, I have had some good experiences with Zope
technology and am leaning that way. Here's the thing though: a lot of
what I'm after in a generic web application framework is already there
with Plone, and it can be turned on and off easily (or so it would
seem). These kinds of things, like user management, authentication, a
sophisticated portlet and layout system, have to be built up in even an
advanced framework like Zope 3. Additionally, the future of Plone
development is using buildout, which should make it possible to quickly
pull together the components needed without too much cruft.
All the above having been said, for the second time I am looking at
choosing Plone. This time around, however, the application will be more
like a one-shot, specific use application and not really resemble
content management at all. I believe this process has given me a much
better understanding of the "Plone as an application vs Plone as a
framework" sentiments.
I'm currently reading through Web Component Development with Zope 3 and Professional Plone Development.
I'm not much of a blogger, but I'll post what I eventually decide to
implement this project in. It may even get released to the world if I
do a good enough job!
