Access 2008 hackfest report: Zotero vs Evergreen

Update: 2008-10-07 As of changeset 10774, the detailed record view in Evergreen's dynamic catalog is now recognized by Zotero.

I really like Zotero. And it works really well with Evergreen's current "basic search"

because it embeds unAPI links that enable Zotero to

consume MODS representations of the underlying

bibliographic records and generate a complete citation based on that.

However, Zotero doesn't work with Evergreen's current "dynamic search" interface - which

is a problem, because it is the default search interface. Evergreen embeds a link to the

unAPI server, and fills in the unAPI link via an AJAX call after the underlying XHTML

has been loaded - but it seems that Zotero doesn't

recognize that the DOM has been changed by the AJAX event and never discovers the unAPI

link. So... I had submitted a challenge to Hackfest to fix this, because I really want to

be able to use Zotero with Evergreen when Project Conifer launches.

And, as with every other Hackfest I have attended, I end up working on my own challenge.

In discussing the problem with William from canadiana.org and Walter Lewis from

Knowledge Ontario, I described how the dynamic interface doesn't use any templating (apart

from entity substitution for localization support), that there wasn't really any way to

inject content server side into the underlying XHTML, and that I really didn't want to have

to dig into the guts of Zotero to enable it to parse the DOM after events had completed.

William asked "so you can't even do a server side include?", which ended up breaking the

problem wide open - because yes, we already use server side includes to identify which DTD

to load for localization purposes.

Step 1 was to modify the detailed record display to put the unAPI link template in place,

and to modify the Apache configuration to pass in hardcoded values for each of the SSI

variables. A quick test and - it didn't work. Uh oh.

That led to much scratching of the head. Was Zotero getting tripped up by the masses of

XHTML elements in the dynamic template that are simply hidden? Did it give up after trying to

parse 100K or so of content? Were there differences in the content types being served up by

Apache? The next step was to compare the content of the "basic search" output against the

"dynamic search" output - and that led to one seemingly innocent difference.

The unAPI server link in the "basic search" output included an absolute link to the server,

while the corresponding link in the "dynamic search" output used a relative link to point

to the root of the server. I didn't think that would be a problem, but eliminating variables

is always good - and when I tested with a hardcoded server link, the Zotero hint icon lit

up and the mystery was solved. Between enabling the record unAPI link to appear in the

static XHTML via SSI and changing the unAPI server link to use an absolute value, Zotero and

Evergreen could work together in harmony.

I haven't committed the fix for this yet to the repository, as I haven't finalized the exact

SSI incantations that will be needed to embed the record ID in the unAPI link. But now you

know the solution, and could tackle the problem yourself if you get tired of waiting for me

and feel inspired. And once the problem is fixed, I'll update the post to let you know what

version of Evergreen carries the fix.

Oh, and my hackfest report slides are attached, in case anyone cares.