Tag Archives: Diazo

How to change element’s ID with Diazo?

A common scenario: on your website all subpages share a common header, but you want a different header on the front page. Let’s say you differentiate between both header versions by their ID attribute and define two different sets of CSS rules for each version.

When applying Diazo rules to a theme file, you therefore need to change header element’s ID, depending on whether the first page or one of the subpages was requested. Here’s a snippet from rules.xml, which does exactly that:

<!-- change header's ID attribute -->
<prepend css:theme="#header-index">
    <xsl:attribute name="id">header-subpage</xsl:attribute>
</prepend>

ID of the header as defined in theme file (header-index) is changed to header-subpage after the rule above is applied.

The rule basically says “Match #header-index element in theme file and use some inline XSL on it”. The “xsl:attribute” tag matches current element’s attribute whose name is “id” (with “current element” being the #header-index element as matched by the outer <prepend> tag). The content of the “xsl:attribute” tag is a new value for the ID attribute.

Nothing spectacular here indeed, but I lost quite some time trying to figure out how to do it in a simple yet efffective way. Very frustrating for such a small task. Various suggestions found on Google simply didn’t work or were a bit too complicated (there must be an easier way to do it, right?).

So to help you avoid all the trouble, I decided to wrote this blog post. Too bad it didn’t exist before. 😉

Plone 4 dev on Lion

Introduction

Recently I upgraded to OS X Lion and here are my notes on how I got my working environment working.

XCode

First things first, you need to setup build tools (gcc, make and the like). On OS X these come as a part of XCode. Even if you had XCode installed on Snow Leaopard before upgrading to Lion, do take time and reinstall it completely. Stuff changed since the white cat and it’s safer to have your build tools up-to-date.

collective.buildout.python

Same story as with XCode. Remove your collective.buildout.python directory entirely and recreate it from scrach. It takes a while, go make yourself some nice tea.

UPDATE: In OSX 10.7.1 readline does not get built because it’s configuration script does not correctly recognizes the OS. You can fix this by appending the following two lines to the bottom of src/readline.cfg in your local checkout of collective.buildout.python and re-running buildout.

make-options =
    SHOBJ_LDFLAGS="-dynamiclib"

egg cache

If you are using a local egg cache it might get tricky. Some people report everything works fine, but several people also report that things were randomly breaking until they had removed all eggs from their egg cache and re-ran buildout. My suggestion? Clear the cache! It takes a while to download all those eggs again, but it beats losing a day chasing readline related SEGFAULTS causing Zope crashes on seemingly random requests:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001131ccf09 in call_readline ()

lxml

If you are using z3c.recipe.staticlxml you are in more trouble. The latest version uses libxml2-2.6.32 and libxslt-1.1.24 and these two break in a very nasty way when you try to access a Plone site themed with Diazo. Zope crashes with no traceback. Attaching gdb to the process spits out the following error:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000001400001c4f
[Switching to process 89119]
0x00007fff8dbcd403 in strncmp ()
(gdb) bt
#0  0x00007fff8dbcd403 in strncmp ()
#1  0x00000001088e5830 in __xmlParserInputBufferCreateFilename (URI=0x1400001c4f <Address 0x1400001c4f out of bounds>, enc=163580032) at xmlIO.c:2412
#2  0x00000001088bc951 in xmlNewInputFromFile (ctxt=0x10985e5b0, filename=0x10407fd30 "/Users/zupo/work/example.project/eggs/diazo-1.0rc3-py2.6.egg/diazo/defaults.xsl") at parserInternals.c:1462
[...snip...]

One solution is to add the following two lines to the [lxml] part of your buildout.cfg:

libxml2-url = ftp://xmlsoft.org/libxml2/libxml2-2.7.8.tar.gz
libxslt-url = ftp://xmlsoft.org/libxml2/libxslt-1.1.26.tar.gz

These tell lxml to build against newer versions of libxml2 and libxslt making those nasty errors go away.

UPDATE: You can just as well use the latest version of z3c.recipe.staticxml which includes URLs to newer versions of both libxml2 and libxslt.

The other solution is simply to not use z3c.recipe.staticlxml at all. It seems that you can now use your system’s libxml provided to you by XCode (located at /usr/include/libxml2). To do this, remove [lxml] from your buildout.cfg and re-run buildout.