Sam’s Greenstone Blog 11/3/2011

sjm84. Friday, March 11th, 2011.

Welcome to week two of my new weekly blog about developing Greenstone.

This week has been quite successful as I have managed to achieve all of the things I set out to do in the previous blog and more. The ‘Oran’ skin is nearing completion now, we just need to get some real users in so we can evaluate both its functionality and its appearance.

As well as there being the small Javascript error in the Berry Basket code that I mentioned last time, there was also a bigger issue that was preventing us from displaying the quick search box on one of the Berry Basket pages. As some of you may know, Greenstone 3 uses technologies such as XML and XSLT to generate the web pages of the Greenstone Reader’s Interface. Greenstone 3 itself is made up of various Actions (that produce the XML for various types of pages) and Services (used by the Actions to do the hard work like retrieving document content or perform a query on a collection), one of which being the Berry Basket service. The quick search box requires information about TextQuery service in the collection that the user is currently within in order to generate a search box that will search that specific collection. The way one of the Berry Basket pages is created however does not make it easy for this collection information to be accessed. It uses a General action who’s ‘c’ parameter stands for Cluster instead of the more-standard Collection, so simply giving the action the current collection in the ‘c’ parameter was not sufficient as it would be for most other pages. We eventually decided that the tidiest fix was to save the collection in the ‘p.c’ parameter and to modify the Receptionist (the part of the code that produces the necessary extra information about that collection) to first look for the current collection in the ‘c’ parameter and if that did not exist then use the ‘p.c’ parameter.

If you’re still here then well done! My average day as a programmer consists of solving lots of these little problems. It may not sound very interesting to the average person but there is definitely a good sense of satisfaction when you find a way to solve these complex problems.

This week I also added a handy little feature that will prompt a user if they make a change in the preferences page and try to leave the page without hitting the “Set preferences” button. It asks them if they want to save their preferences, and if do it will go ahead and save it for them and take them to their new page. Doing this in a way that worked happily on all of the major browsers (Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari) was actually quite tricky. One way that I implemented worked happily on IE and Firefox but refused to work on Chrome/Safari. This ended up requiring a whole different approach, (involving a synchronous AJAX call in the “beforeunload” Javascript event for those who have some Javascript experience).

Anyway, that’s enough for this week. See you next week!

Leave a Reply

You must be logged in to post a comment.