Caveat Lector

One of the (sadly few) nice things that DSpace’s JSP interface did was call out the link for the page you happened to be on in the navigation sidebar. The magic was a class attribute on the current page’s link, plus a bit of CSS.

Manakin doesn’t do that out of the box. But it can, and I just spent entirely too much time making it do so. Y’all get the benefit of my cussing streak.

The first trick is to figure out just what the address of the current page is. Go up to the top level of your theme’s XSLT stylesheet and add this:

<xsl:variable name="currentpage">
  <xsl:value-of select="$context-path"/>
  <xsl:text>/</xsl:text>
  <xsl:value-of select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='request' and @qualifier='URI']“/>
</xsl:variable>

(Incidentally, could somebody with more XSLT-fu than I have kindly explain what the difference is between dri:metadata[@element='request' and @qualifier='URI'] and dri:metadata[@element='request'][@qualifier='URI']? I know there is one, because it keeps tripping me up.)

Now you need your <dri:xref> transformation to take notice. Here’s how it works:

<xsl:template match="dri:xref">
  <a>
    <xsl:attribute name="href"><xsl:value-of select="@target"/></xsl:attribute>
      <xsl:if test="($currentpage)=(@target)">
        <xsl:attribute name="class">
          <xsl:text>current</xsl:text>
        </xsl:attribute>
      </xsl:if>
    <xsl:apply-templates />
  </a>
</xsl:template>

And then you may style at will.

This only works for side navbar links. It doesn’t currently work for the alphabet links at the top of browse-by pages, because they’ve got parameters attached. (If I recall correctly, there may be some URL-space rearrangements in current Manakin versions that might fix this.) Happy designing!

The default Manakin install, just so you know, doesn’t put subject terms on the short item-display page. It’s not hard to add them back, and I recommend it; you’ll see what I did with them in a moment.

Making authors and subjects clickable is a bit trickier. Up-front warning: what I’m about to show you is apparently not in line with the latest version of Manakin, but if you get the idea, making the necessary fixes won’t be hard.

The first problem is that the names need to be URL-encoded or browsers will break amusingly. This leads to the second problem, which is that XSLT 1 doesn’t have a built-in URL encoder. Fortunately, Cocoon does, and you can enable it for your Manakin themes. In your main sitemap.xmap file, add the following just below the root <sitemap:xmap> element:

<map:components>
  <map:transformers>
       <map:transformer name="encodeURL"
src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
  </map:transformers>
</map:components>

Then, between Steps 4 and 5 of the <map:pipeline>, add:

<map:transform type="encodeURL"/>

URL encoding problem solved. (Note: if you mouse over links with this working, they don’t look encoded—that’s okay, everything still works.)

Now you need to go into your theme’s XSLT stylesheet and look for the <xsl:template> with the name “itemSummaryView_DS-METS-1.0-DIM”. If it’s not there, go into DS-METS-1.0-QDC.xsl, find it there, and copy it into your theme’s stylesheet.

After breaking things amusingly several times, I found out what works. Note carefully that I am not using Manakin-default table markup for metadata, because I despise table markup. I’m using definition lists instead, and I’ve made them look like tables with CSS. (Hell, my metadata display is prettier than WorldCat’s. Right-justify your labels, people! It helps the eye.)

<xsl:if test="$data/dim:field[@element='subject']“>
<dt><xsl:text>Subject(s):</xsl:text></dt>
<dd>
  <xsl:for-each select=”$data/dim:field[@element='subject']“>
    <a>
      <xsl:attribute name=”href”>
        <xsl:value-of select=”concat($context-path,’/browse-subjects?subject=’)”/>
        <xsl:copy-of select=”text()”/>
      </xsl:attribute>
      <xsl:copy-of select=”text()”/>
    </a>
    <xsl:if test=”count(following-sibling::dim:field[@element='subject']) != 0″>
<xsl:text>; </xsl:text>
        </xsl:if>
  </xsl:for-each>
</dd>
</xsl:if>

Taking that a bit at a time… frankly, you should wrap all your metadata declarations in <xsl:if> statements as I just did, because otherwise they will show up in Manakin whether they actually have values or not! This is just silly.

I put the bare text “Subject(s)” in the code instead of doing something in messages.xml for it. This is bad, it will be fixed, and you should not do it. Use messages.xml instead.

The rest works out to “for each subject, put a link to the corresponding browse-by-subject page, and add a semicolon and space if it’s not the last subject in the list.” It doesn’t take a whole lot of XSLT-fu to see how it works.

This works just as nicely for authors, and I’ve got that enabled too. (I’ve also split out real authors from advisors, translators, editors, etc. in the code. This took a little doing, and may be worth a separate post.) You can do it too—have fun!

My stupid, for once. I broke Manakin by creating a false XSLT analogy: because there is a last() function, I assumed there had to be a first() function.

Nope. position()=1 is what I wanted, and if I’d been thinking I would have guessed as much.

For the record, Manakin kicks back a really weird error when something breaks in a theme’s XSLT; it pretends that it can’t find a “transaction handler” for the theme. Now I know.

So the Manakin problem that had me tearing my hair out last week was a constellation of Tomcat configuration issues. Tomcat, as I believe I have mentioned before, gives me ulcers. The problems are solved, however, and I hope not to run into them again. If you want to know what they were, ask the local sysadmin, who groks Tomcat so I don’t have to.

Anyway, so Manakin was up, but it wasn’t paying the least attention to my new theme. I scratched my head. I fiddled. I checked out the DSpace wiki. I IMed Tim, who didn’t know what to tell me.

And then I figured it out. The xmlui.xconf file has to be replaced in the working DSpace directory, not in dspace-source. I did that, and hey presto! I have one deathly ugly Manakin theme up and running.

Holy hell, is it ever ugly. Where did my navbar go, for starters? And my logo?

But at least now I can beat on it until it works!

And in other good news, I was wrong! Yep, sometimes that’s good news. The conference organizers weren’t in the market for happytalk, so I am back on the menu. More news when I have it.

So I built what I thought was the crude beginning of a workable Manakin theme and dumped it up on the test server. Whereupon it stubbornly failed to work.

Here we go again. I’ve been fighting with this thing for nearly a week. No quick answers, just “500 I can’t find dspace.cfg.” Which is horse manure. The tech lists are no help: “it’s some kind of a configuration problem, not sure what.” Yeah. Thanks. Guessed that.

Next step is to do this the slow way. There’s a known-good DSpace/Manakin combo on that server. I’m going to restore it, copy it to my local drive, compare it to what I’ve got, and if I have to, start replacing files bit by bit until it breaks again, whereupon I’ll at least have narrowed down the problem!

Would be easier if the compile-deploy cycle weren’t such an amazing pain in the posterior. Die, -D, die!

I’ll let y’all know what it was once I get this licked.

Tables. Bloody tables. Manakin isn’t quite as table-infested as the JSP URI, but it’s still got plenty of bloody tables where they shouldn’t be.

A comment I left in the code today:

<!-- NO CAPES! -Edna Mode. NO TABLES! -DS -->

I also notice that the summary-view table allows blank metadata items (abstract, description). This is stupid. I believe I have fixed it. Once I’m sure, I’ll let you know.

Also, argh, VERBOSITY. Less noise on the pages, please! Turning the bitstream table into a list allows me to get rid of the table headers. This is a good thing.

Also, double-argh, thumbnails at the end of the file listing, when they’re the first thing anyone wants to consider! Fixed that one too.

And inflicting MIME types on users sucks. I gotta find a way around that one; I don’t care what METS allows.

Edited to add: I have a notion for that last. Get the Bitstream Format Registry to export itself to something XMLish, then call it via the MIME type in METS. Kludge, if I can even get it to work, but way better than inflicting MIME types on users.

Hm… there is also input-forms.xml, which might be pressed into service in a pinch…

So one of the problems with DSpace in both its JSP and Manakin incarnations is that authors get lumped together with editors, translators, advisors, and many other sorts of contributors in a number of the displays. This is confusing at best and outright wrong at worst. I promised several of my colleagues that I’d fix that in Manakin.

I’m trying to start slowly here, with the simple display of titles and authors found in (for example) the Recent Submissions section on community and collection pages. Found that bit (and let me congratulate the Manakin devs on the nice, sensible display choices here):

        <div class="artifact-title">
            <a>
                <xsl:attribute name="href"><xsl:value-of select="@url"/></xsl:attribute>
                <xsl:choose>
                    <xsl:when test="$data/dc:title">
                        <xsl:copy-of select="$data/dc:title[1]/child::node()”/>
                    </xsl:when>
                    <xsl:otherwise>
                        <i18n:text>xmlui.dri2xhtml.METS-1.0.no-title</i18n:text>
                    </xsl:otherwise>
                </xsl:choose>
            </a>
        </div>
        <div class=”artifact-info”>
            <xsl:choose>
                <xsl:when test=”$data/dc:contributor”>
                    <xsl:copy-of select=”$data/dc:contributor[1]/child::node()”/>
                </xsl:when>
                <xsl:otherwise>
                    <i18n:text>xmlui.dri2xhtml.METS-1.0.no-author</i18n:text>
                </xsl:otherwise>
            </xsl:choose>
            <xsl:text> </xsl:text>
            <span class=”date”>(<xsl:copy-of select=”substring($data/dcterms:issued/child::node(),1,10)”/>)</span>
        </div>

So, okay, for title we’re grabbing the first dc:title element, and for author we’re grabbing the first contributor element regardless of its qualifier (which is the problem that I want to fix), and for date we’re going straight to something (element unimportant, as I read it) with a qualifier of “issued”.

Huh. So if I read this right, we’re assuming that no two DC elements happen to have the same qualifier for any reason. I suspect that works out fine in practice (though what about dc.contributor and dc.creator?), but it seems, well, brittle. Hacky. Kludgy.

What I don’t quite see how to do is create an XPath that takes both element and qualifier into account, since they’re in different namespaces and may not have any structural relationship to each other. (Where’s the documentation on this particular METS profile, anyway?) Anybody got a brilliant answer?

Just reading through the messages.xml file, I see some things that Manakin has streamlined compared to the JSP interface, and I entirely approve.

They haven’t, however, gotten rid of the unnecessary task-choice workflow step, which makes me mutter various things not safe for a PG-13 weblog. I’m hoping I can go in and fix this, but I suspect it’s going to be a Java problem, and that may be tougher than I can deal with.

Sigh. Back to fixing language.

Anyone using Manakin: Do not—DO NOT—send it live without a thorough read of the messages.xml file in the i18n folder in the config folder. Just in a quick read, I’ve found misspellings, incorrect apostrophe use, and similar things that send a librarian’s spine shivering as though nails had run down a nearby chalkboard.

I’m fixing them on my end, and when I’ve time, I’ll shoot a corrected version at the developers. In the meantime? Don’t embarrass yourself or your institution. Read the file and fix it!

Edited to add: Also, verbosity and redundancy. Argh. Librarian thing. Sometimes we need to be beaten with copies of Strunk and White. Avoid needless words, dammit, especially on the web! (Expostulations are never needless.) I just changed “If that is the case” to “If so.”

Edited to add (again): Even better. “The following represent ways in which you can log in. Choose the appropriate method by following the link.” changed to “Log in via:”.

We should totally hold a contest. Whoever can reduce the wordcount in DSpace’s message file most while retaining appropriate clarity wins.

So this is the design I’m supposed to imitate in the new Manakin-based repository design. Except for the Arial (ugh), it’s not bad, passing over lightly that the CSS code looks like what I might have written when I was new to the spec—that is, disorganized and messy.

But I have a design problem. Well, several. One is that I don’t have a reverse-video repository logo. That could be gotten around; I can just make one. But if I do, I may cause brand confusion between the repository and the larger organization, and I can’t think of anything calculated to cause me more grief. If I don’t, then I have the problem of trying to fit a multi-colored logo into that nice red border. Yucko.

Okay, so we get rid of the red border at the top and make it white, demarcating it with the thin red line. The nav sidebar can stay more or less as it is, white-on-red. That will also let me move the breadcrumbs into the header, which is a feature of the default Manakin design that I quite approve.

Now there’s the two-logo problem. Two logos? Yes, two logos: one for the repository, and one (optional) for the community or collection. How do you put two logos on a page such that they don’t clash? And why is the real page title living in the body of the page and not the header?

Okay, so let’s be clever about this. If there’s a logo, we put it in the logo spot in the header. If not, we use the default repository logo. Either way, proper title goes in the header. Yes! I like this. (Others may not, if they are concerned about the repository “branding” itself. Me, I’m pragmatic. The repository “brand” isn’t worth diddly-squat. Letting campus communities brand their own collections is worth a lot.)

Now to figure out how to make it happen… title shouldn’t be hard, but I’m not sure about that logo…