MicroViews: Now with Android goodness
I have just released MicroViews for Android onto the development version. This is some very basic work but it is the start of the process so that I can start refining the functionality.
Thanks to the fact that the Android browser is based on a version of webkit, this means that it was quite easy to port the code which creates the iPhone view across. All that I had to really do was perform a couple visual tweeks so that it fits in with the Android style.
Currently the Android views don’t show any image previews in the coverflow style that exists on the iPhone version but I hope this will change soon. The key issue here is dealing with the landscape event. On the iPhone it is possible to detect a change in orientation through JavaScript. On Android I believe that it is possible to disable the screen reorientation completely if you put your phone in to landscape. What this means is that I need to modify my image coverflow so that it will function correctly in both landscape and portrait.
Making this modification may pay dividends for the iPhone view as well. Currently the image navigation component is relying on a gesture detection library, but getting the sensitivity setting of the library right is proving to be tricky. In a landscape view I would possibly rely more on buttons to navigate as opposed to using gesture functionality.
There is another slight caveat that I found about Android. This cold possibly be down to my lack of experience with the platform, but the history component that I used for the iPhone view does not appear to work. The component works by appending fragments onto the end of URLs. Fragments are like query strings except they are preceded by a # and when appended don’t force the browser to reload the page, but they do usually leave an entry in the browser history. This means that the back button on the iPhone version will go back to the previous page of MicroViews as opposed to straight back to the original page. On the Android browser this does not appear to work at the moment. I need to investigate further to see if this a case of the fragments not getting entered into the browser history, or the back button on Android does not behave in the expected manner.
Taking stock and mopping up the mess I made of EPrints
So on our Language Box and other deriviative systems we thought it might be appropriate to upgrade the comments plugin (sneep) and install the meprints profile system. This meant we could go forward in a nice future proof kind of a way. In order to do this we needed to have an enoumous stock check. We still run on EPrints 3.1.0 because its part of our svn tree. What I needed to do was disentagle the work we had done from the EPrints 3.1.0 code.
The main cause of this problem was that I had no understanding of EPrints and only a basic grasp of perl when we started writing Language Box. The Faroes project which I was paid on was also massively behind schedule. This resulted in me having to learn EPrints as I went along and hack up something that worked fast with minimal fuss. Lanauge Box became fairly successful and institutions wanted their own installations of it. This meant the code had to be made portable. However their was no time to clear up the mess I had made which basically meant I did the bear minimum to make the thing deployable and then essentially copy pasted 3 times to make our respective deployments. All those deployments are now up and running so there is time to step back take a breath and make a genuinely portable system of robust plugins which can survive an EPrints upgrade process.
So without further ado let me give you the top 10 ways to avoid making a hash of your EPrints install when doing a large customization:
Rule 1: NEVER edit Session.pm if there is one file that you will absolutely not recover from it’s this. also there is an easy way to avoid editing it see rule 6.
Rule 2: Don’t edit anything in perl_lib/EPrints. Make copies with a new name and new package. That way these files wont be over written when you upgrade.
Rule 3: Everything in the Plugin/ directory which you do should be kept in the appropiate place in archives/YOUR_REPOSITORY/cfg/plugins/EPrints/Plugin etc. This is a really good way to keep track of what you’ve actually done.
Rule 4: Everything you do should be a plugin. EPrints has plugins for almost everything which means you should be able to do almost all funtionality in plugins.
Rule 5: For everything you want to do which doesnt seem to be a plugin think really hard. Are you SURE it’s not a plugin? Really SURE? Are you SURE you need this functionality? Really SURE?
Rule 6: If you have followed rule 5 and you are still really sure then kludge a plugin, a kuldgin as I like to call them, using namespace over writing. This is feature/artifact of perl, from one package you can write in another package. Add methods to the DataObj::EPrint good example of where you might want to do this. To do it :
make a Plugin (yes a plugin) in your local cfg (see rule 3). start the plugin file in the normal way:
package EPrints::Plugin::MyPlugin;
use strict;
our @ISA = qw/ EPrints::Plugin /;
#now for the clever bit
package EPrints::DataObj::EPrint;
sub mysubroutine{
return(“foo”);
}
That has added mysubroutine to DataObj::EPrint so you can now
my $eprint = EPrint::DataObj::EPrint->new($session, 23); #get eprint 23
print $eprint->mysubroutine(); #prints “foo”
Rule 7: learn about cfg/cfg.d/plugins.pl. This file lets you disable plugins you dont want to use or map you modified plugins over other plugins. For example use MyReview.pm everywhere you would usually use Review.pm – very powerful. It also lets you define where plugins apear around about the place.
Rule 8: for plugins which use a cgi script for whatever reason (usually ajax) make a directory in cgi which has the same name as the plugin for example cgi/myfirstplugin where all the cgi used by MyFirstPlugin.pm can be found. It makes it much easier to see what youve done and if you want to deploy the plugin somewhere else you grab the plugin file and the directory and you well on the way.
Rule 9: Give each plugin its own phrase file. I got into a hidious mess where my zz_local.xml phrase file was about a 4000 lines long and it wasnt clear what phrases belonged to what plugin.
Rule 10: If your plugin needs configuring put all the config options in a cfg/cfg.d/my_plugins_config_options.pl that way the user only has to go to one place edit the options and different repositories using the same plugin can have different options.
In conclusion obey rules 1-10. If I’d known this stuff when I’d started we probably wouldnt have needed the first 6 months of the OneShare project.
Apache gives white screens using perl
I was recently having a problem where every so often (6 or 7 clicks) navigating around my web app it would return a white screen. restarting apache would temporarily fix the problem but then something would happen which triggered it and it would happen constantly from that point. more frustratingly it didnt seem to leave anything in the error log.
I tried a number of things to diagnose the problem. Eventually I wrote a script which took the pid of the apache thread serving the request. turns out it was always the same pids that served up the empty pages. the problem was bad programming on my part. i was creating large perl objects and not disposing of them. im guessing something like a perl stack overflow happened killing mod perl. apache hands off to mod_perl ,which is now dead, so returns 0 which apache serves and the web browser interprets as an empty response.
i removed the offending package and was unable to repoduce the problem. moral of the story: cyclic references break garabage collection and mod perl doesnt croak when it dies…
MicroViews: Appearing In The Wild
It has been a bit of a quieter week on the MicroViews front as I have been helping out on other projects. But I did manage to get a big goal ticked off over the last week. MicroViews has now been applied to the ECS public facing people pages. You can see an example of it in action on Dave Millard’s people page. The library is now working across all of the people pages providing views for all of the EPrint links on the publications pages.
MicroViews is also being pushed through the ECS internal news system in order to encourage adoption of the library on personal user pages. It is hoped that I can use the initial interest generated by doing this to get MicroViews onto the lecture notes pages for ECS. One problem that I will potentially have with getting MicroViews onto the notes pages is that they are within the SSL protocol. Since MicroViews is currently only running over the http protocol and it is only proven to handle requests to http addresses more testing will be required when hosting MicroViews from an http address and making requests to http servers from an https page. If the repository is also an https address then I can’t see that there would be a problem.
A potential solution to this problem would be to create a bridge script. This unfortunately would complicate the installation of MicroViews somewhat but it may end up being a necessary evil. The bridge script would be hosted on the same domain that is including the MicroViews library. So if I were running a server at https://example.com I would install the bridge there. An additional option would then be added to MicroViews that instructs it to append the bridge callback to any requested URL. The bridge would then be a transparent passthrough that crosses the http/https divide. In effect the script would take the EPrints URL, make the request and then just echo the output back to the script. The problem of crossing between http and https then would no longer be a problem as this is a browser enforced security restriction.
Sneep 1.5
So part of our work on oneshare was to refactor some of our plugins to be easily reinstallable on other eprints systems. One of my personal niggles was Sneep. Sneep was written by Rory Mc’Nicol at the ULCC. Richard Davis and Rory realised that tagging and making tags on eprint records and indeed other datatypes was something cool that people wanted to do.
They made a tagging system called SNEEP (Social Networking Extentions to EPrints). I used this on the Oneshare project and found it was good. But it was written for an earlier version of eprints and was a real headache to install. It also had a number of problematic bugs particularly with installations using https.
On closer inspection of the code i found there code was a bit rushed and would probably have benefitted from the power of hindsight. Since I could see the module had potential Marcus Ramsden and I reimplimented SNEEP to make it more stable and much easier to install. In doing so we reduced the requirements so SNEEPing can only be done on EPrint objects. This vastly reduced the complexity of the code.
The new implimentation can be installed on 3.2 (svn trunk) by simply unzipping the folder into your eprints directory and ‘mv’ing the contents of YOUR_REPOSITORY to the folder containing your repository and install.
Then change eprint_render.pl
my $sneep_main = $session->make_element( 'div', id=>'ep_sneep_main' );
$sneep_main->appendChild( $session->get_repository->call(
'render_sneep', $session, $eprint, 'comment' ) );
$sneep_main->appendChild( $session->get_repository->call(
'render_sneep', $session, $eprint, 'note' ) );
where you want the comments and tags to apear.
next then run
bin/epadmin reload YOUR_REPOSITORY
bin/edadmin update_database_structure YOUR_REPOSITORY
bin/generate_static YOUR_REPOSITORY
bin/generate_abstracts YOUR_REPOSITORY
and the jobs a goodun. Feedback going to eprints from this is there needs to be hooks in eprints render so i can register a few key places in the code i want to render plugins. that would eliminate the need to mess with eprint_render.pl and make this process as trival as unzipping a directory.
but why stop there. if this process is as simple as copy and paste then we can trust a machine to do it. So why not work on the code tim brody and dave tarrant wrote for a demo at OR09 to install install plugins. An idea we are now calling the “EPrints Bazaar”.
tarrants vodcast of the bazaar http://users.ecs.soton.ac.uk/dct05r/or09/
#oneshare