While cleaning up on the remoteinclude sprinting we did last week at the post-conference sprint, I came across Windmill. Windmill looks like a really promising candidate for anyone wishing to do some non-trivial browser based testing of their web applications:

Windmill implements cross browser testing, in-browser recording and playback, and functionality for fast accurate debugging and test environment integration.

I'd be curious to know if any members of the Plone/Zope community have had any experiences with it. Also, if you've simply become curious and would like to try it out for yourself (and then report back) but are intimidated (or simply put off) by the lengthy installation instruction, here's a one-stop buildout including the particular python that windmill needs, that will get you going:

[buildout]
python = python
parts =
    python
    pythonbin
    windmill

[windmill]
recipe=zc.recipe.egg
eggs =
    simplejson==1.9.1
    windmill

[python]
recipe = zc.recipe.cmmi
url = http://www.python.org/ftp/python/2.5.2/Python-2.5.2.tgz
executable = ${buildout:directory}/parts/python/bin/python2.5
extra_options=
    --enable-unicode=ucs4
    --with-threads
    --with-readline
    MACOSX_DEPLOYMENT_TARGET=10.5 # uncomment this, if your're not on MAC OS X

[pythonbin]
recipe = plone.recipe.command
command = ln -s ${python:executable} ${buildout:bin-directory}/python

Update: Martijn Peters points out, that you can use newer versions of simplejson, you just need to stick to the 1.9 branch for the time being:

"because I assume it's the 2.0.0 API change that makes them use 1.9.x on their instruction pages. It works just fine with 1.9.3 anyway, haven't tried 2.0.3 at all."

I've updated the buildout above accordingly. Also, if you already have a working python2.5 on your system (unlike yours truly who hosed his Mac OS X 10.5 python2.5 ages ago) you can reduce the buildout to this snippet:

[buildout]
parts =
   windmill

[windmill]
recipe=zc.recipe.egg
eggs =
   simplejson <=2.0.0dev
   windmill

Out of a whim I decided to join today's CSS Naked Day. After all, as a Plone Site there is no need to be ashamed :-)

Deliverance is the New Kid on the Block[tm] in the Plone world. I find the whole concept very intriguing and have decided to give it a try on both of my current new projects. (No risk, no fun, eh!?)

One of the two projects is smaller in scope where I am both the Zope/Plone developer and the HTML/CSS handyman and the other a larger affair together with another Zopista and an external web agency with up to five more people, none of which is experienced with - or much interested in - Plone, so I am curious, how Deliverance will hold up in these two quite different scenarios.

Now, if you just want to dip your toes into the proverbial water, I suggest you check out Martin Aspeli's Deliverance recipe (does that man ever sleep?) However, Martin's recipe, along with any other tutorial that I found floating about, uses deliverance in its so-called proxy mode where a second daemon is fired up that mediates between the web- and application server. This is not optimal, of course, as it pretty much defeats the whole point of the WSGI concept, so I set out to create a setup, where Plone would be themed by Deliverance configured as a WSGI middleware. Forthwith my notes:

I conducted my test on Mac OS X 10.5.2 with Python 2.4.5 installed via Macports. I didn't use virtualenv (although I should have) but had to make sure throughout the whole process, that python2.4 was used (as opposed to Leopard's default 2.5.1). To do that, I installed easy_install and setuptools explicitly for 2.4:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python2.4 ez_setup.py
sudo python ez_setup.py -U setuptools

Before dealing with Deliverance I set up a WSGI enabled Plone instance. The buildout provided by repoze.plone proved to be the best candidate to do so (believe me!)

svn co http://svn.repoze.org/buildouts/repoze.plone/trunk repoze.plone
cd repoze.plone
python2.4 bootstrap.py
./bin/buildout

I then fired up the new instance as per instructions:

./bin/supervisord
./bin/addzope2user admin admin

I then could add a Plone instance foo at localhost:8080 just as always. I then stopped the zope instance so:

./bin/supervisorctl stop zope

and then restarted it using paster:

./bin/paster serve etc/zope2.ini

and sure enough, localhost:8080/foo was still there!

Now the only thing missing was Deliverance itself. To make it available for the instance, I simply easy_installed it into my system (this is the part, where next time I'll use virtualenv!):

sudo easy_install-2.4 Deliverance

This enabled me to add the following snippet to etc/zope2.ini:

[filter:deliverance]
paste.filter_app_factory = deliverance.wsgimiddleware:make_filter
theme_uri = file:///%(here)s/layout.html
rule_uri = file:///%(here)s/rules.xml

To use the deliverance as a filter in the WSGI stack I just had to add it somewhere. I chose to add it just after zope2 itself, so that my pipeline section looked like so:

[pipeline:main]
pipeline = egg:Paste#cgitb
           egg:Paste#httpexceptions
           egg:repoze.retry#retry
           egg:repoze.tm#tm
           egg:repoze.vhm#vhm_xheaders 
           errorlog
           deliverance
           zope2

Before restarting zope (or rather 'reserving it with paster') I had to add the rulefiles mentioned in the filter declaration. Eager as I was at this point, I simply borrowed the trivial default rule and theme from Martin's recipe, spiced it up a little with one of repoze.org's own rule files and created a etc/rules.xml file that looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<rules xmlns:xi="http://www.w3.org/2001/XInclude" 
    xmlns="http://www.plone.org/deliverance">
    <prepend theme="//head" content="//head/link" nocontent="ignore" /> 
    <prepend theme="//head" content="//head/style" nocontent="ignore" /> 
    <append theme="//head" content="//head/script" nocontent="ignore" />    
    <append theme="//head" content="//head/meta" nocontent="ignore" />
    <append-or-replace 
        theme="//head" 
        content="//head/title"
        nocontent="ignore" />
    <append-or-replace theme="//div[@id='content']"
        content="//div[@id='region-content']"
        nocontent="ignore" />
</rules>

and a etc/layout.html file that looked like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<title>The Theme</title>
</head>
<body>
<h1>A theme</h1>
<div id="content">
</div>
<hr>
<address></address>
<!-- hhmts start -->Last modified: Fri Mar 16 09:33:37 CDT 2007 <!-- hhmts end -->
</body> </html>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>layout</title>
</head>
<body>
</body>
</html>

Now I could stop the foreground paster process, fire it up again, hit reload in my browser and voila! Bob was my proverbial Uncle!

Next, I'll give mod_wsgi a try. But, of course, not the one for Apache but... yup, there's a mod_wsgi for nginx, too, yay! Stay tuned...

P.S. I'd like to take this opportunity to thank Chris, Tres and Paul for their efforts to connect Zope and Plone with non-techies and non-Zopistas. I'm very confident that you guys are creating some serious groundwork here that will benefit us immensely during the next eight years! Rock on!

I was just about to explain to somebody via email how to switch skins per url in Plone 3 when I realised I should rather blog it and send him the link instead of just explain it to him privately, so here it goes...

Add a file skinswitcher.py to the top-level of your product with the following contents:

def setskin(site, event):
    if event.request.URL.find('127.0.0.1') > -1 \
        or event.request.URL.startswith('https'):
        site.changeSkin('NuPlone', event.request)

then include the following snippet in your top-level configure.zcml:

<subscriber
    for="Products.CMFPlone.interfaces.IPloneSiteRoot
         zope.app.publication.interfaces.IBeforeTraverseEvent"
    handler=".skinswitcher.setskin" />

This particular example simply enables the NuPlone skin when the site is accessed via https or 127.0.0.1 (instead of localhost) and otherwise uses the default skin which is my usecase 99% of the time but it should be easy now to modify skinswitcher.py to your particular needs.

I got an urgent call from a client yesterday evening. He needed 150 Windows Postscript fonts converted for Mac OS X by next morning. Hooray! Well, for those of you who care to remember, such stuff used to be the domain of rather expensive and cumbersome Software, so rejoicing wasn't exactly what I did. Turns out, though (and that's the reason I'm blogging this) that the situation is far less bleak than back in 1997 when I used to deal with such issues regularily: because now there exists a very fine Open Source solution for font editing (and in my case more importantly) font conversion: FontForge.

It requires X11 to run on Mac OS X but the beauty is, of course, that it can perform conversions also from the command line. But the fun doesn't stop here: it also features its own scripting language and a handy example for batch converting fonts so the potential nightmare of creating those 150 TrueType fonts turned out to be a breeze.