In the wide world of USQ Library today turned into another day of digging through code, asking why and then progressing on with fixing things. Today’s strange problem was trying to work out why variables that seemingly were global variables weren’t marked as global variables yet were working. This revelation turned out to be a require of the relevant file into function scope – I’m not sure why I didn’t think to look for that first but the excess of globals threw me off. The function in question had around 12 other globals marked in various places so it isn’t completely out of place. Par for the course for the last week really and Business provided the most interesting aspect of the day.

The next most interesting revelation of the day appears to be Sedona. Sedona is a system that the Faculty of Business appear to be running up to help support them in obtaining AACSB accreditation. Sedona appears to a database which is shared between apparently 220 institutions. Apparently the approved method of importing is to use a CSV file, there is no way of adding new fields to the system unless it is deemed to be useful to “all Australian universities”. An example of such is two relatively pointless HERDC and ERA fields as well as an FOR08 field that was for Bond University. The FOR08 field is particularly useless with some 1400 FOR codes in a standard HTML multiline select box.

Sedona doesn’t appear to offer any form of integration services so the fact that they could integrate with ePrints via SWORD (deposits) or OAI-PMH (harvesting) is sounding impossible even though it would be a great standard way to send data around. The suggested synchronisation involved FTP but details are light on the ground.

Apparently the system doesn’t work properly with Chrome to the point that it won’t let you login claiming you need IE, Firefox or Safari. The system isn’t normalised as well with the author names fields (first name, middle name and last name) being stored as individual fields in the database (e.g. fname1, fname2) and limited to five authors. For overflow there is an “et al.” multiline textbox. The system does have a method of adding co-authors however this is distinct and is again a multiline select box. There is another free form box for citations which makes sense as they limit the list of periodicals (drop down select list) and lack enough information to build most citation types from the data that the system stores.

The system does appear to have given some thought to an export with an Access database being generated with appropriate tables. Access, whilst not perhaps my preferred database system, is perhaps one of the better choices for data export and certainly beats sending CSV or XLS files around. There is the proprietary aspect to Access but there could be no option at all and at least maintains type data better. It also appears that this form of export is the way of adding extra fields that might be required by the University to store extra information. It wouldn’t surprise me if an Access database isn’t the preferred synchronisation tool though that personally scares me. But at least they have thought about it which is a good start.

Overall I look at the system and think we could integrate it into ePrints and increase the overall value of our data anyway. We could handle the few extra fields that Sedona appears to add with the extra item types. The extra datasets are exactly that: datasets. ePrints has workflow to handle editing items to do what it needs. It would be less limited and give us more power to do what we need.

Reports appear to be the systems strong point. There is a prebuilt CV and various other rather trivial reports for a member. There is a set of aggregate reports that I haven’t looked into and there appears to be a rather picky way of formatting things for the AACSB requirements (including printed CV’s in a particular format – I hope AACSB doesn’t cover IT related areas given the backwards requirements).

The fun task I ended the day with was returning to work on the monstrous PHP application I’ve been fighting with all week. The particular point I’m at is adding plugin functionality to a section of the code base. Since I’ve been incorporating the Joomla! Framework into the system, doing this turned out to be relatively trivial. At the point where I wanted the plugin trigger I load a file called ‘notifier.php’. This loads in the Joomla! framework bootstrap file which defines a while bunch of things (JPATH_BASE, JPATH_ROOT, etc) that Joomla! uses and loads the relevant files plus a few other files to get the system started off the bat. The ‘notifier.php’ file also defines a class aptly named ‘Notifier’ which extends JDispatcher. JDispatcher is the work horse of the Joomla! event subsystem from which plugins derive. The Notifier constructor loads up a particular directory and opens all of the files in it and tries to create new classes in the format plgNotifierFilename similar to how Joomla!’s plugin infrastructure works. This then registers those classes with the notifier class for use. Then in the original file I use JDispatcher’s “trigger” method to send a message to all of the registered plugins and the integration is done. In the original file there is only 4 lines of code added to load the file, create the class and trigger the message – plus a comment summarising this as well. It is one of those things where the framework makes life really easy to extend systems in a flexible manner. Now if I want to attach multiple plugins to extend that particular bit of code it is easy to do and with the framework it is easy to define multiple plugin triggers.