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.