Lørem Ipsum

Perhaps if our mantra was not entirely ASCII, we wouldn't have so many encoding bugs. It's easy to manage character encodings with Python, but we need proper test cases. Please include non-ASCII characters whenever you write test strings. They needn't be as silly as the heading of this post.

Templates with (almost) no effort at all!

The jbot-package ("Just a bunch of templates") is a popular little tool that helps out with the customization of Plone. By following a simple naming convention, you can override stock templates with zero configuration.

Now, by popular demand, comes a new version that supports overrides for a specific layer. The road for this landmark achievement was paved with monkey-patches and nasty hacks, but in lack of a better word I'll call it elegant.

And what's more remarkable, it's still perfectly compatible with both Zope 2 and 3. So hurry to your keyboard and customize away without breaking a sweat over configuration woes.

Getting started with Zope on Google App Engine

Thanks to a patch published by Kapil Thangavelu, it's quite straight-forward to get set up to use Zope on Google's App Engine. Yesterday, Guido van Rossum provided a zipimport-implementation which makes it easy to import Python libraries as a ZIP-archive, which was previously not possible in the remote environment.

To make it easier for everyone to get started, I thought I'd publish my setup.

You'll need to dump a ZIP-archive of the packages you want to use in your application directory. Download zope.zip to get the basic necessities.

Put Guido's my_zipimport.py in the Python path and bootstrap the importer using the following code:

  import my_zipimport
  import sys

  my_zipimport.install()
  sys.path.insert(0, 'zope.zip')

You'll probably want to look at Ian Bicking's instructions for getting a Pylons-based application set up and the customize it to point to an application factory such as this:

  import os

  def application_factory(global_conf, zcml='site.zcml', devmode='off', **kwargs):
      zcml_conf = os.path.join(global_conf['here'], zcml)
      devmode = ( devmode.lower() in ('true', 'True', 'on') and True) or False
      return getWSGIApplication(zcml_conf, devmode)

  def getWSGIApplication(configfile, schemafile=None, features=()):
      return WSGIPublisherApplication()

  class WSGIPublisherApplication(object):
      def __call__(self, environ, start_response):
          start_response('200 OK', [('Content-type', 'text/plain')])

          yield "Hello World!"

This is very preliminary, but should give some starting pointers. For an example on how a WSGI application can interact with the Zope publisher, you may want to look at ore.wsgiapp.

A necessary evolution

Plone as we know it is essentially an intranet document server that also lends itself to building dynamic websites. It's widely recognized that between every major release of Plone, the content publication machinery changes radically, in stark contrast to the underlying content management system which largely stays the same. These changes are seen as a necessary evolution for some, while others worry that the right balance between progress and stability hasn't been found. At any rate, they represent quite an effort to introduce extension points that a content management and publishing system needs in order to meet the various needs of a modern internet population.

When Apple went from System 9 to Mac OS X, they kept the general look and feel, but decided to radically change the underlying platform. This was indeed a necessary evolution. Looking back at the past releases of Plone and the changes incurred between them, they instead resemble the shift from Windows 2000 to XP: Under the hood, there were only miniscule changes, but features were added on the higher layers to support new functionality. Most importantly, you
could still invoke a DOS-prompt right from the "Start"-menu. It was thus said to be backwards-compatible. You couldn't run Panzer General though.

The proposed changes to the next generation of Plone are a welcome change of direction, marking a departure from the document-centric approach that's been dominating the current installment. This is not to say that it was wrong, but it's certainly much more applicable for intranets at large. At the same time, there's a promise of cutting away a great deal of complexity which in this case seems only to be a good thing. There are only few changes to the underlying platform. You can still go to the ZMI by adding /manage in the address bar of your browser, not to do anything really useful though, because the moving parts are no longer exposed there.

And yet, I worry. Are we renovating a house that the authorities have already removed from the map to clear the path for a new highway? And perhaps more importantly, are we in a position to change those plans such that it's built using Zope technology instead of Django? In case you haven't noticed, a new version of Python is out and it runs on a new version of Zope. This version is really great, because it doesn't have code that looks like this:

  for idx in _indexes:
     exec("manage_add%sForm = %s.%s.manage_add%sForm" % \
          (idx,idx,idx,idx))
     exec("manage_add%s     = %s.%s.manage_add%s" % \
          (idx,idx,idx,idx))

Instead, it has a clear and concise approach to almost every problem you'll want to tackle on the web. It's radically different from the previous version and there's no obvious migration path. But it's a necessary evolution.

Plone is on the right track. It needs to upgrade its locomotive.

Meet Dobbin

If you've been with Zope since at least 2004, chances are you've heard about Ape, the adaptable persistence engine, which allows you to create a ZODB mount point that uses an SQL database as storage [1]. Ape uses native column types to store attributes, if a schema is provided, else the attributes are stored using the python pickle format.

Enter Dobbin, an adaptable persistence engine which does away with the complexity of Ape by relying on SQLAlchemy for relational storage, and zope.schema for schema declaration [2]. The codebase is slim, and developer documentation is provided as doctests.

Tables are created on-the-fly with a 1:1 correspondence to interfaces with no inheritance (minimal interface). As such, objects are modelled as a join between the interfaces it implements. This approach allows using the database as a catalog in an way that's fully integrated with zope.schema. As an example, listing folder contents is a matter of acquiring the joined mapper of ILocation and IDCDescriptiveProperties, and doing a select by _parent_.

[1] Florent Guillaume on object-relational mapping in Zope
[2] Project page for z3c.dobbin

Mind control

While letting Emacs take over your brain with dabbrev-expand is a comfort, typing M-\ isn't, at least not on a Mac.

The cure was prescribed to me today in #emacs: (global-set-key [?\s-\\] 'dabbrev-expand). It even works with both the left and right super key.

Magical mystery portlets

This is part rant, part awe.

If you were ever stuck trying to convince the test-browser from Zope to add a portlet to your Plone site, watching it completely ignoring your request, here's a little hint.

The portlet adding machinery makes use of a quite unusual (to me, thus far unknown) feature of the request processing machinery in Zope; if you have a field with the name ":action", it will actually override the form action, but this is all transparent to the user; or developer. You'll never know what hit you.

Naturally, now that it's occurred to me, it seems obvious how it all worked. But perhaps this is a bit too clever, at least if unaccompanied by some commenting in the template and/or code. At any rate, now it's documented in at least one place.

In closing, to add a portlet you'll need to first point your test-browser to:

 /++contextportlets++plone.rightcolumn/+/portlets.Login 

or whatever portlet you wish to add to which column, and then click "Save".