teiJournal

Spent most of the day hacking at the appearance of the site, with (I think) pretty good results. I've added variables in the db storage code so that a logo can be added to the journal title, and configured a range of different elements in the base and user CSS.

One major problem I'm having is with pipeline caching. Even though I've specified type="noncaching" on the whole pipeline, the system whereby data stored in the db as xsl variable elements, and pulled out via XQuery to be used as part of an XSLT transformation, is still suffering from caching. This will be a problem when we have a GUI which enables users to change that data. I'll have to find a way to tell Cocoon to clear its cache.

Doug sent over a lot of new versions of the logo, which has changed a little; circles now touch where previously they didn't. I traced this version and created a range of PNGs at various sizes and opacity.

The current versions of the IALLT logo on the site are rather pixellated GIFs which won't be resizable, and we need versions suitable for various locations and sizes, as well as for watermarking, so I traced one to create an SVG version and rendered it into bitmaps of various sizes. Sent the results to D. and H. for approval.

I decided that since the site rubric pages are mostly drawn from the site.xml file in the database, it would make sense to build the menu from there too, so I replaced the code which constructs the menu from a little block of XHTML in the database with XQuery which parses the site.xml file to create a menu. This entails adding a new type of <div> to the site.xml file, which simply constitutes a link, rather than content; this is used for the contents page, which needs its own XQuery and XSLT to function. This seems to be working fine.

Whatever was wrong with Tomcat seems to be fixed, so we were able to get on with deploying teiJournal on it. Rather than try to deploy our own custom-built WAR file, with time running out for the release deadline, we decided to go the tried and trusted route and start from the default Cocoon+eXist WAR file, and at the same time refine our documentation for doing such things. The full documentation is posted here.

Spent most of the day with Greg trying to deploy ANY webapp successfully on the new development Tomcat. No joy whatsoever. Not even an original download of the Cocoon/eXist WAR file will deploy. There's clearly something wrong with the way this Tomcat is set up, but we're frustrated in trying to figure it out by the fact that we don't even have read access to the Tomcat configuration files.

This is completely frustrating. If we can't get this going tomorrow, I'll have to consider deploying the teiJournal code into the existing Tomcat, new Java stuff and all. That's a bit scary, but we can't afford to spend a week trying to debug a screwed-up Tomcat install when we have a deadline looming.

We have a dev Tomcat working on Lettuce now, so that'll be the place to deploy the app. The problem now is how best to deploy the application itself under this Tomcat.

What we'll probably do is this:

• Change web.xml to rename the application from "Cocoon" to "teiJournal".
• Also change web.xml to set all encodings to UTF-8 (some are still 8859-1 in the default setup).
• Deploy the application itself in a directory called ialltjournal in the webapps directory of Tomcat.

Right now, we don't have permission to restart Tomcat, so we can't have it find the webapp where we've placed it; we've tried "deploying" it using the Tomcat manager, but since it's not a WAR file, that doesn't seem to work; telling it to deploy an application from the directory where its files are seems to cause those files to be deleted. Once Greg has control over Tomcat, we can restart it and see if it finds the new webapp or not.

Completed the system for the main site pages. They're based on a single document, in TEI, which has a number of <div> elements in its body. The document is stored in the db, and in response to a request asking for a particular id, the correct <div> is turned into a page. In the process, I abstracted quite a lot of XSLT content from the article XSL base file into a general file (general.xsl), so that it's available to other processing pipelines.

One thing remains to be done: we need to set up a page of indexes which harvests all the key data (names, references, etc.) into lists that can be browsed, linking back into articles. I'm not exactly sure how to approach that yet.

When search hits are displayed in the contents page, they now use only the preceding and following text() elements, unless these are less than 60 characters in length respectively, in which case another one is retrieved.

Spent the day on this, since we have a deadline to release the journal site at the end of November. The search/contents page is basically finished. Details:

• The search text box is visible by default, along with a search button, and a More... button.
• Pressing the More... button shows the search filters.
• This is the case UNLESS a search has previously been done using the filters; in that case, the filters are visible, and the correct items are selected in them.
• The page itself configures its main heading based on whether a search has been conducted, or it's just showing the whole list of articles.
• When there are search hits, the hits are shown in context, highlighted, in a block below the article entry in the TOC table.

Tested on a range of browsers. Seems to work well everywhere, although it looks ugly on IE6.

One remaining issue is trimming the size of the search hit contexts. Right now, I'm taking the two preceding and the two following text() nodes, without checking how big they are; I should trim them to a maximum length just to keep the output under control.

The next stage is to implement a site title bar and menu, probably via XSL includes, based on strings in the database; the menu will be a horizontal single-level thing, because we have hardly any content to put in it. I've written to the editors to get some content for the site pages.

Following that, I need to implement an addition to the article display code which allows the same search to be run against an article, and for it to have the same text highlighted as on the search page, so that, having found hits in an article, you can go to it and see them all highlighted there too. Not quite sure yet of the best way to approach that.