HCMC Blogs

On late duty, and trying to get the bugs out of a browser display component on Moses.

The idea of retrieving the complete entry for a component morpheme in the context of its container entry was a good one, but the execution up to now has been quite confusing; the component morpheme entry was just dumped into the middle of the container entry without much differentiation. I've now re-worked that whole system, so that the component morphemes are listed after the hyphenated morpheme breakdown in the form of a tab control, with one tab for each morpheme; clicking on a tab retrieves the entry for that morpheme and shows it in the tab box. It retrieves in a similar way to the previous system, detecting if a copy of this morpheme data already exists on the page and cloning it if it does, but it makes the display more obviously separate from the main container entry. As usual, most of the time spent was on the appearance and functionality of the tab control; in addition to normal tab features, it needs to be able to collapse itself again (when you click on the tab for an entry which is already displayed), and I wanted to get the borders working correctly. They still don't quite work in Opera, but they're good in Gecko and Webkit. It works in IE8, although the rounded corners and box-shadow aren't there.

On my local machine, I've also ported the environment to our new build of Cocoon+eXist+FOP, with no problems at all. Tomorrow, I'll carry that over to the Pear location.

Did the last two and the summarizing notes. Total time for the work about 11 hours (useful for SA to know if he's on the committee next year).

Leaving early.

I have a really solid build script working now. At the beginning, it checks whether Tomcat is running, and if so, shuts it down; then it does the build, does all the patching (with a placeholder for the Analyzer patch if we get a working one), and links in the testing material; then it restarts Tomcat, and sends Firefox to the test site. That's pretty much perfect. I tried turning on the webapp.samples and webapp.test-suite in the Cocoon local.build.properties, but the results were mixed. The Samples page works, but not the "Blocks with samples" page; the eXist page comes up, but all the links are broken and you can't get the server status. Doubtless there are ways to fix this, and if I can do that, then we can really release our build alongside the main builds on the site, because it would be functionally complete. I think it might be worth putting time into that. Alternatively, I could just fix the links manually in a static build and post that, but that would make updates a bit annoying. We should figure out whether all that's wrong is weblinks, or whether there's something else that needs fixing.

This morning I learned how to do patching as part of an Ant build, and integrated the patch for the Snowball Analyzer into the script. However, the patch process fails, so I think the patch must have been generated against an earlier version of the target file. Waiting for confirmation from AR about this. Meanwhile, I'm having trouble making a specified target run or not based on a property in the properties file, for some reason.

Two to go -- probably Monday -- then summarizing notes on Tuesday.

Lots of admin stuff ate into my day, so I couldn't get away on time.

Progress today:

• Integrated one CJK font (TakaoMincho) into the FOP config and set up the test code to use it for Japanese text. We limited this to one font, because adding it seems to increase the base memory footprint of Cocoon by about 80MB; that's significant, and there's no need to overload the test environment by adding more.
• Added a series of new targets to the Ant build file to first remove the symbolic link to the test environment inside the build tree before doing anything else (because otherwise the build clean process deletes the target directory's contents!), then recreate the link at the end of the process. It also checks to see if there's a link in the Tomcat webapps directory on my local machine, and if not, creates one. This means the test site will work out of the box once you start up Tomcat at the end of the build. This involved learning more Ant stuff, which is useful. I'm getting the hang of it now.
• Tested the new build with the Moses code, and everything works just great.

I think I'm almost done with this. Remaining bits and pieces:

• Have the build check whether Tomcat is running at the beginning, and if so, shut it down. I found some example code for that here.
• Have the build restart Tomcat at the end of the process, then start Firefox pointing to the test site. This will make it a single operation to update from SVN, build the app, and get the test site up and running.

I've been looking into the differences between the Lucene syntax and the old index system, and realized that I'll have to rewrite some of my backend code for e.g. Mariage to get the advantage of Lucene; and also that Lucene itself requires the use of its XML syntax in order to get support for wildcards. I think the best solution to this is to rewrite my xqSearchUtils Java library so that it can spit out Lucene XML instead of the code aimed at the old eXist. This shouldn't be too hard to do, and it'll make creating good Lucene search interfaces easier.

Five more to go...