Fixed a server crashing bug, answered some questions on the mailing list, looked into a GS3 thumbnail issue which ultimately Dr Bainbridge ended up solving, and started on fixing the validation issues with the OAI server for Greenstone 2.

Mainly bug fixing.

There were a couple of outstanding unicode bugs that needed fixing (the rest were fixed the week before) such as in MetadataXMLPlugin. There were a few changes that had been made to GS3 which caused it to cease compiling properly which also required fixing. Finally, there was also the ticket where GS3’s List Users didn’t display all the details for a new user. That’s now been fixed too.

This week has been a very productive one for us, our list of tickets is down to only a few and soon we will be able to begin testing in preparation for release.

The Internet Explorer issue I mentioned last week turned out to be much more confusing that I had anticipated. Despite the fact that the servlet seemed to be getting the message to add a berry to the Berry Basket it would then report that there were no berries. After some debugging we eventually tracked the problem down to caching. The first time Berry Baskets is enabled it performs a call to the servlet asking how many berries there are (and of course there are none). Internet Explorer then cached this response so that the next time Berry Baskets asks what berries are in the basket it returns the same response without even asking the servlet, resulting in no berries showing up in the basket.

To fix this caching problem we decided to introduce a new parameter that can be used in a Greenstone URL to specify custom response headers. This parameter is specified in JSON and can take a list of header values. So to disable caching of the response we would use hhf=[{“name”:”Cache-Control”, “value”:”no-cache”}] in the URL of the page we request.

Another pair of tickets we closed were to do with changing various parts of the interface when a collection uses the Lucene indexer. For example, Lucene does not search for terms if they are too common (e.g. “the”, “a”, “of” etc.) so we need a message to show up on the search page informing the user that one or more of their search terms were too common and therefore were ignored.

Another minor ticket that was closed was allowing <store_metadata_coverage value=”true”/> to be placed in the collectionConfig.xml file to enable metadata coverage information to be stored at build-time. This feature already exists in Greenstone 2 and was not possible in Greenstone 3 until now.

Next week I will be working on the remaining outstanding tickets. If we manage to close them all we will move onto testing to make sure that there isn’t anything that we’ve missed.

It was mainly Greenstone 2 bug fixes that week for bugs pointed out by helpful members on the mailing list such as Diego: there was a server.exe crash, a unicode issue with List.pm, and the same plugin also didn’t process the slash that separates metadata fields very well, there was a problem with authentication when using the local library server. All of these are fixed now, and all except for the last require updates of single files, so that they can work fine for Greenstone 2.84 users after that.

For the first time in a month or so (maybe longer) I’ve actually managed to write this on a Friday instead of the following week!

Anyway, this week has consisted of more “oran” skin/interface development. A large part of this has revolved around repairing various aspects of the Berry Baskets functionality. Although the original Berry Baskets problem (that prevented it from functioning at all) was fixed a long time ago, new problems have been “created” with the recent changes to various parts of the interface and testing has revealed some problems we were not aware of until recently.

One of the largest problems we discovered was that the drag and drop Javascript code (the code that allows users to move berries to the Berry Basket) we use did not work at all in Internet Explorer 9, despite working fine in earlier versions of Internet Explorer as well as Firefox and Chrome. After doing some research on the subject we discovered that it was a problem with a Javascript library we use. We use the Yahoo User Interface (YUI) library to provide us with drag and drop functionality and we discovered that versions of the library before version 2.9.0 (the latest version at the time of writing this) all have this problem as well. As we were using YUI version 0.9.0 it was assumed that upgrading to this latest version would break other parts of the program. Fortunately this wasn’t the case and the upgrade went smoothly and the problem is now fixed.

With the recent changes to the way the classifiers (Subject/Organisation etc.) are displayed (see my previous blog entry) it was not surprising to find that Berry Baskets did not work properly with the documents displayed in that view. Fortunately, thanks to the previously mentioned problem we now have a much better understanding of the Berry Basket code and as a result it was fairly straight forward to fix this problem. There were also several more minor issues that have also been fixed.

Next week I will continue fixing up the interface and Berry Baskets as there is still more to fix (for example, in Internet Explorer the berry system does not properly maintain its state from one page to the next). Once these issues are resolved I will be able to move on to some of the other things we want to get done before we release 3.05.

As there wasn’t much to report two weeks ago, I will combine the previous 2 weeks together.

Work continues to go well on Greenstone 3, our list of tickets (basically our TODO list) is getting smaller at a steady rate. Only a few things remain to be done on the new skin and most of the other tickets are fairly minor in comparison to getting the new skin ready. So things continue to look good for a 3.05 release in the near future.

We found a good solution to the problem I discussed a few weeks ago, we now have it so that only sections can be collapsed/expanded in the table of contents and not the individual chapters. These can still be manipulated in the document by using the + and – icons next to the title of each chapter. The chapter links in the table of contents now simply takes you to that chapter by jumping you down the page, rather that the “focusing” idea we were considering, where clicking on a link would collapse all sections of the document except the one you clicked on. We also added a “back to top” link so that it was easy to get back up to the table of contents again.

We have used this same collapse/expand idea in the classifier pages (e.g. Subject/How to/Organisation  etc.) so that, rather than loading a new page when a user clicks a subject (for example) we now remain on the same page and “expand” the subject. This results in a much more intuitive way to browse subjects than the previous implementation which would only “expand” one subject at a time.

The query result page has been tidied up and now displays messages like “Displaying 1 to 20 of 100 documents” and has next and previous buttons go to the next and previous pages of results (this obviously existed in the old Greenstone3 skin but it’s new for this skin). If you enter only one or two search terms then it will display information such as “cat occurs 5 times in 3 documents”, however for three or more search terms it shows a compressed view such as “the (25739) farming (228) cat (5)”.

This week will mostly be focused on cleaning up the skin so that it will be easy for Greenstone users to modify it however they wish.

Most of the last two weeks were spent on making the final changes to the work Dr Bainbridge had already done to get Greenstone to work again if you have moved the Greenstone installation. It is now the case that if you relocate your GS2 installation that running the Greenstone Server Interface (GSI) will get the server successfully running from its new location, on both Linux and Windows. Underneath, there are differences (because the apache web server for Linux and Mac has its current location fixed into many of its files, which then need to be adjusted upon relocation), but the different operating systems provide the same “reset-gsdlhome” target in gsicontrol.bat and .sh, which is what the GSI calls whenever this application’s launch script is run. The reset-gsdlhome target can also be called from the command-line. The changes that needed to be made for this had the nice side-effect that gsicontrol can be run from any directory.

At the end of last week, we started looking at the GS284 bugs that Diego found.