• <gslib:langfrag> was to replace a whole lot of XSLT statements instantiating a javascript array in header.xsl. It took a bit of messing about, but util.xsl now calls a new Java method to generate the Javascript array declaration and initiation, and this called from document.xsl and documentbasket.xsl (instead of header.xsl) using the new <gslib:langfrag> element.
• The gs2-library servlet was not working. After a lot of debugging, there were several fixes required. One was for the main servlet page, one for a collection page, one for viewing a browsing classifier. The major bug was in the way stylesheets were merged in GSXSLT.java. This has now been improved.
• During the above, the lack of clear error messages on where things were going wrong pointed to another problem: insufficient debugging information when XSLT transformations go wrong. XMLTransformer’s TransformErrorListener has now been improved (and TransformingReceptionist updated) to do better error reporting when transformations of in-memory DOM objects fail.
• Revisited recent unsatisfactory changes to the ant force-stop-tomcat target, since an ant restart did not always properly stop and start tomcat. Now the process has been improved by making the stop-tomcat target do a socket test in a wait loop to ensure that tomcat is properly stopped before proceeding. Subsequent calls to ant start therefore can only happen after this, even if tomcat commands are chained such as happens during “ant restart” or “ant stop start”.
• Running GS3-server.sh on Ubuntu wasn’t launching the browser. This was the old problem already seen in GS2 of the gs3-setup.sh script setting up env vars for wvware which then conflicted with the native libraries used by Linux for running graphics applications. The problem was already solved for GS2 by the introduction of the wvware.pl script which would set up the environment for wvware, and all that was required to get things to work for GS3 was to stop setting the env for wvware in gs3-setup.sh (and giving executable permissions to the wvware binary included in the Greenstone3 binary).
• A new target ant clean-logs has been added, which deletes catalina.out and greenstone.log and can help speed up the debugging cycle.
• Currently, am looking at a “debuginfo” button that will appear next to the login button and which display a page with the various options for o= that can be appended to the URL when debugging the XSL transformation process, as well as other URL suffixes.
• Once that’s done, I will return to testing the Greenstone 3 binary and start with attempting to perform the Greenstone 2 tutorials with GS3.

The very start of last week still required more work on the scripts that would handle translations made in Google’s Translator Toolkit. A couple of additional scripts were written.

Thereafter and until yesterday, the work has been mostly centred on GS3’s usersDB:

• getting the output of txt2usersDB to work as input to usersDB2txt and viceversa as well as allowing txt2usersDB to run in append mode,
• creating a new program to modify a user’s details in the DB which then gets called by the new targets config-user and config-admin (for setting the admin password) in build.xml
• getting the releasekit to update the admin password where the user provides this

There were a few questions in the mailing list that required some investigating, and today I finally got round to looking at getting Java to write out a bit of javascript that was previously done in XSLT where it looked unsightly and verbose. Unfortunately, I couldn’t test it when I tried out the Document Structure Editor. I got a blank section and could not type into this the new gslib:langfrag element that I was meant to test.

Instead, I decided to write some handy instructions into the Wiki’s Greenstone 2 FAQ which will help explain how to do some common tasks. The questions added to the FAQ are on how to manually build collections, how to get better error reporting in GLI, how to run GLI in debug mode, how to launch, use and copy from the DOS prompt, how to launch Windows Explorer and where to find the Windows key.  From experience, these instructions will be particularly helpful when answering Mailing List questions, as Greenstone users can be referred to these new FAQ items, armed with which they will then be better equipped to help us in the debugging process.

I’m writing this a day early this week because I will not be working tomorrow due to Easter, I still have a bit to report however.

This week I decided to re-think one of the previous decisions we made in regards to viewing documents in Greenstone 3. In Greenstone 2 you can normally only view one section at a time and therefore it is difficult to get a grasp of where you are in the document and also how big the document is. For this version of Greenstone 3 we decided that we would take the opposite approach and that, by default, viewing the document would always show the whole document instead of just a section. This approach works find for small- to medium-sized documents, but for larger documents the page begins to get too long. To resolve this problem I have decided to implement a mixture of the two approaches. Now, by default, when you view a page it will only show the section you asked for, but it will also give you a full table of contents and links on the page that allow you to view other parts of the document without needing to go to a new page. New sections are dynamically loaded when they are needed and there is also an option to expand all the sections if you do want to see the whole document at once.