First the easy one, iOS 5;

if ([[UINavigationBar class] respondsToSelector:@selector(appearance)]) {
    [self.navigationController.navigationBar setBackgroundImage:navigationBackgroundImage forBarMetrics:UIBarMetricsDefault];
}

Note the test on the navigation bar class to check if it supports the UI proxy extensions. This must be done in iOS 4 otherwise a crash will result.

Now for iOS 4 we have to create a category, fortunately this is very simple;

@implementation UINavigationBar (CustomBackground)

- (void)drawRect:(CGRect)rect
{
    UIImage *navBackgroundImage = [[UIImage imageNamed:@"navigation-background"] stretchableImageWithLeftCapWidth:0.0 topCapHeight:0.0];
    [navBackgroundImage drawInRect:rect];
}

@end

The drawRect: method is not called in iOS 5 so it is safe to leave this category in your app. Just as a small side note, Apple has deprecated strechableImageLeftCapWidth:topCapHeight: in iOS 5 in favour of resizableImageWithCapInsets:.

// NSDictionary+QueryStringBuilder.h

#import <Foundation/Foundation.h>

@interface NSDictionary (QueryStringBuilder)

- (NSString *)queryString;

@end

// NSDictionary+QueryStringBuilder.m

NSString * escapeString(NSString *string) 
{
  NSString *s = (NSString *)CFURLCreateStringByAddingPercentEscapes(NULL,
		  (CFStringRef)unencodedString,
		  NULL,
		  (CFStringRef)@"!*'\"();:@&=+$,/?%#[]% ",
		  kCFStringEncodingUTF8);
  return [s autorelease];
}

@implementation NSDictionary (QueryStringBuilder)

- (NSString *)queryString
{
    NSMutableString *queryString = nil;
    NSArray *keys = [self allKeys];

    if ([keys count] > 0) {
        for (id key in keys) {
            id value = [self objectForKey:key];
            if (nil == queryString) {
                queryString = [[[NSMutableString alloc] init] autorelease];
                [queryString appendFormat:@"?"];
            } else {
                [queryString appendFormat:@"&"];
            }

            if (nil != key && nil != value) {
                [queryString appendFormat:@"%@=%@", escapeString(key), escapeString(value)];
            } else if (nil != key) {
                [queryString appendFormat:@"%@", escapeString(key)];
            }
    }

    return queryString;
}

@end

Using this category is very simple;

NSDictionary *queryParameters = [NSDictionary dictionaryWithValuesAndKeys:1, @"page", nil, @"enabled", 25, @"size", nil];
[queryParameters queryString]; // This will return "?page=1&enabled&size=25"

You can get the sourcecode as a gist.

Introduction

I am finally getting started with playing around with some Android development and the first order of business is getting my development environment set up. I’m going to be doing most of my development on OS X using Apache Maven and Textmate, of course in your situation you could use your favourite text editor, I side more with vim fans I’m making the assumption that the reader is comfortable with the terminal, additionally a dosage of no fear if you are following these steps.

Homebrew

To get the ball rolling we’re going to start with everyone’s favourite missing package manager, Homebrew. If you haven’t got Homebrew installed already then you’ll be glad to know that installation is pretty simple to do;

ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

If you haven’t got Xcode installed yet this script will install it for you. If this is the case you may want to go get a drink as it may take some time.

Android SDK

Now that we have Homebrew installed we can get the Android SDK tools installed. Thanks to Homebrew this is a simple process and you don’t even have to visit a website, this appeals to the exceedingly lazy developer in me. Just go ahead and run;

brew install android

Once Homebrew has installed the Android SDK you can just straight away run the android command thanks to Homebrew setting everything up for you. So go ahead and run the Android SDK and AVD manager by running android on the command line. Then you can make your AVD and install the desired versions of the Android SDK. You may need to update your android tools since it appears that the Homebrew formula is a little out of date with the current version, but this is simple enough to do.

At this point let’s create an android project to make sure that everything is ready to go. I created a HelloAndroid application targeted for Android 2.1;

android create project --package com.example.helloandroid \
  --activity HelloAndroid \
  --target 3 \
  --path <path-to-project-folder>/HelloAndroid

Then to make sure that everything is set up right and working fire up your Android emulator and then run ant install. Once this is done go ahead and make sure the app runs on the emulator. Assuming this works then run ant uninstall to uninstall the app from the emulator.

Apache Maven

Whilst I do prefer to avoid a full blown IDE I do like some automation in places and Apache Maven is a big old help with this. The first thing to do is get maven installed, again thanks to Homebrew this is simple;

brew install maven

Now we need to get the project set up with maven. We will be using the Maven Android Plugin to help us out. The first thing we need to do is remove the following files;

rm -r bin build.xml build.properties libs

Next we setup our environment for the Maven Android Plugin. We need to set a ANDROID_HOME environment variable. In .bash_profile add the following line;

export ANDROID_HOME=`brew --prefix android`

Setting up the project for use with maven needs the following pom.xml file created in the root of the project;

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.helloandroid</groupId>
  <artifactId>helloandroid</artifactId>
  <packaging>apk</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>HelloAndroid</name>
  
  <dependencies>
    <dependency>
      <groupId>com.google.android</groupId>
      <artifactId>android</artifactId>
      <version>2.1.2</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
  
  <build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>com.jayway.maven.plugins.android.generation2</groupId>
        <artifactId>maven-android-plugin</artifactId>
        <configuration>
          <sdk>
            <path>${env.ANDROID_HOME}</path>
            <platform>1.6</platform>
          </sdk>
          <emulator>
             <avd>standard</avd>
             <wait>6000</wait>
          </emulator>
          <deleteConflictingFiles>true</deleteConflictingFiles>
        </configuration>
        <extensions>true</extensions>
      </plugin>
    </plugins>
  </build>
  
</project>

Once the pom.xml file is created then we can see if it is all set up right by running;

mvn help:describe -Dplugin=android

Running this should give details about goals available for the android maven plugin. For reference here are the goals;

Name: Maven Android Plugin - maven-android-plugin
Description: Maven Plugin for Android
Group Id: com.jayway.maven.plugins.android.generation2
Artifact Id: maven-android-plugin
Version: 2.8.3
Goal Prefix: android

This plugin has 16 goals:

android:apk
  Description: Creates the apk file. By default signs it with debug keystore.
    Change that by setting configuration parameter
    <sign><debug>false</debug></sign>.

android:deploy
  Description: Deploys the built apk file, or another specified apk, to a
    connected device.
    Automatically performed when running mvn integration-test (or mvn install)
    on a project with instrumentation tests.

android:deploy-dependencies
  Description: Deploys all directly declared dependencies of <type>apk</type>
    in this project's pom.
    Usually used in a project with instrumentation tests, to deploy the apk to
    test onto the device before running the deploying and running the
    instrumentation tests apk.
    Automatically performed when running mvn integration-test (or mvn install)
    on a project with instrumentation tests.

android:dex
  Description: Converts compiled Java classes to the Android dex format.

android:emulator-start
  Description: EmulatorStartMojo can start the Android Emulator with a
    specified Android Virtual Device (avd).

android:emulator-stop
  Description: EmulatorStartMojo can stop the Android Emulator with a
    specified Android Virtual Device (avd).

android:generate-sources
  Description: Generates R.java based on resources specified by the resources
    configuration parameter.
    Generates java files based on aidl files.
    
    If the configuration parameter deleteConflictingFiles is true (which it is
    by default), this goal has the following side-effects:
    - deletes any R.java files found in the source directory.
    - deletes any .java files with the same name as an .aidl file found in the
      source directory.
    - deletes any Thumbs.db files found in the resource directory.

android:instrument
  Description: Runs the instrumentation apk on device.

android:internal-integration-test
  Description: Internal. Do not use.
    Called automatically when the lifecycle reaches phase integration-test.
    Figures out whether to call goals in this phase; and if so, calls
    android:instrument.

android:internal-pre-integration-test
  Description: Internal. Do not use.
    Called automatically when the lifecycle reaches phase pre-integration-test.
    Figures out whether to call goals in this phase; and if so, calls
    android:deploy-dependencies and android:deploy.

android:pull
  Description: Copy file/dir from device.

android:push
  Description: Copy file/dir to device.

android:redeploy
  Description: Redeploys the built apk file, or another specified apk, to a
    connected device. This simply tries to undeploy the APK and re-deploy it.

android:undeploy
  Description: Undeploys the built apk file, or another specified apk, from a
    connected device.

android:unpack
  Description: unpack library.

android:zipalign
  Description: ZipalignMojo can run the zipalign command against the apk.

If you see that then you are all set and ready to go. I’m hoping to get some more blog posts up about my development exploits on android. If you want to read more about the maven android plugin then have a look at their website http://code.google.com/p/maven-android-plugin.

Update 1: I did have some troubles with the android:emulator-start goal. But it turned out I had missed the emulator block in the maven-android-plugin configuration block. Found this information in Sonatype’s Maven Reference Guide. Also I corrected a typo in the pom.xml definition.

This has been an exciting period for me and I think that I am finally starting to get a handle on things. On my list of things to get my head around is creating libraries for Objective-C for use in iOS applications and possibly, in a boon for reuse, OS X as well. I settled on creating an Objective-C wrapper for the Github API which I will probably take further and develop into an iOS application over time, ideally a one that is targeted at both the iPhone and the iPad as my new job has yet to see me make anything for Apple’s tablet.

What I am really interested with this project is, what makes a good API that is nice and easy to use for the average iOS developer? I already have the start of an answer is that it should presumably echo the existing Cocoa Apis as I have noticed that these are quite consistent at the high level which as a result makes them easier to learn or at least take a guess to a reasonable start to using an as yet unmet API.

I hope over the process that I will do a better job at keeping my somewhat unloved blog a little more up to date with my experiences.

I suppose the other important part is the project page for the library can be found at Github.

I have taken to using VirtualBox in my day to day development work. The reason for this is it provides a nicely isolated development sandbox which I can go ahead and clutter up with the usual tools, then when things go wrong I just have to trash the machine and clone from an existing image that I have pre-made. So far this has made life much easier for me.

My preferred approach to running my machines is to start them up in headless mode and then shell into them using a static IP assigned through the VirtualBox host-only network. The only issue with using headless mode is that there is potentially no indication of the state of the machine, basically when can I shell into my machine? Since I was already using conky to report the status of my host machine I thought that I would add to my conkyrc so that I could see the state of play with regards to VirtualBox and the machines available to it.

I decided to make use of the VirtualBox Python SDK to write a small application that can report on the status of my machines. The deb installation of VirtualBox supplied by Sun/Oracle contains the SDK as well, I am unsure if this is the case for the version of VirtualBox OSE available on the Ubuntu repositories. Also I don’t know what the state of play is with other linux distributions. You may want to download the SDK anyway as this includes all of the documentation for using the API.

So with that out the way onto the script that I created to report the status of my machines;

#!/usr/bin/env python
from vboxapi import VirtualBoxManager
import getopt
import sys

opts, args = getopt.getopt(sys.argv[1:], "", ['conky', 'vbox-version'])
useConky = False
for o, a in opts:
        if o == '--conky':
                useConky = True

virtualBoxManager = VirtualBoxManager('XPCOM', None)
virtualBox = virtualBoxManager.vbox
for o, a in opts:
        if o == '--vbox-version':
                print virtualBox.version
                sys.exit(0)

machines = virtualBox.getMachines()
for machine in machines:
        machineName = machine.name
        machineStatus = "null"
        machineStatuses = {
                0: 'null',
                1: '${color red}powered off$color' if useConky else 'powered off',
                2: '${color red}saved$color' if useConky else 'saved',
                3: '${color yellow}teleported$color' if useConky else 'teleported',
                4: '${color red}aborted$color' if useConky else 'aborted',
                5: '${color green}running$color' if useConky else 'running',
                6: '${color yellow}paused$color' if useConky else 'paused',
                7: '${color red}stuck$color' if useConky else 'stuck',
                8: '${color blue}teleporting$color' if useConky else 'teleporting',
                9: '${color blue}live snapshotting$color' if useConky else 'live snapshotting',
                10: '${color blue}starting$color' if useConky else 'starting',
                11: '${color blue}stopping$color' if useConky else 'stopping',
                12: '${color blue}saving$color' if useConky else 'saving',
                13: '${color blue}restoring$color' if useConky else 'restoring'
                 }
        machineStatus = machineStatuses.get(machine.state)
        print machineName, "-", machineStatus

This script will accept the following arguments when executed;

virtualboxstatus [--conky] [--vbox-version]

  --conky
    Adds any additional colors for conky to render.

  --vbox-version
    Displays the installed version of VirtualBox then exits.

Once this script is made we just need to add it to our conkyrc in order to render the status of our machines. In my conkyrc I added the following;

${color red}VIRTUALBOX STATUS$color - Version ${execpi 600 ~/bin/virtualboxstatus --vbox-version}
${execpi 1 ~/bin/virtualboxstatus --conky}

Here’s a screenshot of this script in action;

Currently my OS of choice for my VMs is Debian Lenny. This is a rundown of the commands that need to get up and running with rvm.

Edit
Rather then taking this “gem install” approach you can just run;

Thanks to Wayne for the really quick comment

First start off by install ruby and rubygems from the Debian repositories;

apt-get install ruby rubygems

Once this is done I like to make sure that I have the latest version of rubygems, this is done through the handy rubygems-update gem since the Debian rubygems package disables gem update --system;

gem install rubygems-update
/var/lib/gems/1.8/bin/update_rubygems

Once this is complete you now need to install rvm;

gem install rvm

The next step after installing the rvm gem is to finalise the installation by running the rvm-install command. Depending on your setup you may be able to run this directly if the rubygems bin directory is on your path. If not then you will need to run;

/var/lib/gems/1.8/bin/rvm-install

Now we need to follow the final setup phase for rvm which is given to us by rvm-install. In /home/<username>/.bashrc you need to comment out the line [ -z "$PS1" ] && return and add the following code to the end of the file;

if [[ -s /home/<username>/.rvm/scripts/rvm ]]; then
  source /home/<username>/.rvm/scripts/rvm
fi

Once this is done you will need to logout of your shell and back in again for the settings to take effect. If you run rvm list you should now see that you have no rvm managed versions of ruby installed and then there is the system version which is what aptitude installed for us. Also a warning about the command file not being found. This is solved by;

apt-get install file

Now before installing an rvm managed version of ruby there are a final few dependencies that need to be installed;

apt-get install build-essential curl zlib1g-dev libreadline5-dev libxml2-dev libsqlite3-dev

Then all you need to do is run;

rvm install 1.8.7

You now have a ruby environment setup as I set mine up ready for use. One thing to note is that to install gems you should use rvmsudo rather then sudo.

I have a small confession to make. Whilst I do love the Zend Framework I have been seeing other frameworks and indeed languages behind it’s back. One of these frameworks include Django for Python. Admittedly every time I start up in a new framework I do always seem to come back to the Zend Framework fold but I guess that must be down to the fact that I just prefer PHP, it’s where I feel comfortable.

There was one feature that stuck with me about Django though, and that was it’s template language. I found this to be very enjoyable to do, and to be honest in my view of things using PHP as my template language wasn’t cutting it anymore in my books. I suspect that some people will strongly disagree with my arguments but then again this is what I feel is the beauty of PHP, there are so many tools out there that I can make them fit with my preferred style.

Fortunately the Symfony crowd have come to the rescue with, what I think is, a nice little template language called Twig. It resembles the style of templates found in Django with curly braces all over the place rather than PHP tags. Plus it lets you include blocks of templates in with other templates, this appealed to me because I found that

<?php echo $this->render("view-file.phtml"); ?>

I have been getting stuck into more features of the Zend Framework and thought that it would be fun to write an integration layer so that Twig can be used in Zend Framework. The solution I came up with works for default views and views contained inside modules.

To start with I created a wrapper around the main Twig_Environment class. This class is responsible for loading a template and then rendering it with the supplied data.

<?php
class ZExt_Twig extends Zend_View_Abstract
{
  
  private $_twig = null;
  
  public function __construct($applicationRoot, $modulesDir = "")
  {
    $twigLoader = new ZExt_Twig_Loader($applicationRoot, $modulesDir);
    $this->_twig = new Twig_Environment($twigLoader);
  }
  
  protected function _run()
  {
    $template = func_get_arg(0);
    echo $template->render($this->getVars());
  }
  
  protected function _script($name)
  {
    return $this->_twig->loadTemplate($name)
  }
  
}

I will come onto the ZExt_Twig_Loader class shortly. The two methods _run and _script are both overriden methods from Zend_View_Abstract. These get called when the render method of the parent class get’s called. The _script function is responsible for loading the appropriate Twig template and then returning it.
The _run method is called when we are ready to hand off to the Twig rendering engine. The first argument to this method should be the template object that was returned by the _script method. Note that when the render method is being called we are passing in an array of any data that might have been assigned to the view.

Next the ZExt_Twig_Loader class is responsible for loading the appropriate template file from the standard Zend Framework application directory structure.

<?php
class ZExt_Twig_Loader extends Twig_Loader
{

	/**
	 * @var string
	 */
	private $_applicationRoot = null;

	/**
	 * @var string
	 */
	private $_modulesDir = null;

	/**
	 * @var string
	 */
	private $_viewsDir = null;
	
	/**
	 * Constructor.
	 *
	 * @param string	$applicationRoot The application root.
	 * @param string	$modulesDir The directory where all modules are found.
	 * @param string	$viewsDir The path where views should be located in both the application root and
	 * modules directory.
	 * @param string 	$cache The compiler cache directory.
	 * @param boolean	$autoReload Whether to reload the template if the orginal source changed.
	 *
	 * @see Twig_Loader
	 */
	public function __construct($applicationRoot, $modulesDir, $viewsDir = "/views/scripts", 
		$cache = null, $autoReload = true)
	{
		$this->setApplicationRoot($applicationRoot);
		$this->setModulesDir($modulesDir);
		$this->setViewsDir($viewsDir);

		parent::__construct($cache, $autoReload);
	}

	/**
	 * Returns the source of the next view to load based on the supplied name.
	 * The name in this instance should take the form 'module/controller/action',
	 * 'controller/action', or just 'action'.
	 * 
	 * @param string	$name The view to load.
	 * 
	 * @return array An array consisting of the source code as the first element, and
	 * the last modification time as the second one or false if it's not relevant.
	 */
	public function getSource($name)
	{
		$name = $this->_parseName($name);
		$templateFilePath = $this->getApplicationRoot();
		if (!is_null($name['module']))
		{
			$templateFilePath .= DIRECTORY_SEPARATOR.$name['module'];
		}
		$templateFilePath .= DIRECTORY_SEPARATOR.$this->getViewsDir();
		$templateFilePath .= DIRECTORY_SEPARATOR.$name['controller'].DIRECTORY_SEPARATOR.$name['action'].$name['extension'];
		
		if (!file_exists($templateFilePath))
		{
			throw new Zend_Exception("The template file $templateFilePath does not exist.");
		}

		error_log($templateFilePath);
		return array(file_get_contents($templateFilePath), filemtime($templateFilePath));
		
	}

	public function getViewsDir()
	{
		return $this->_viewsDir;
	}

	public function setViewsDir($viewsDir)
	{
		$this->_viewsDir = $viewsDir;
	}

	public function getApplicationRoot()
	{
		return $this->_applicationRoot;
	}

	public function setApplicationRoot($applicationRoot)
	{
		$this->_applicationRoot = $applicationRoot;
	}

	public function getModulesDir()
	{
		return $this->_modulesDir;
	}

	public function setModulesDir($modulesDir)
	{
		$this->_modulesDir = $modulesDir;
	}

	private function _parseName($name)
	{
		$matches = array();
		preg_match("/(\..*)$/", $name, $matches);
		$name = substr($name, 0, strpos($name, $matches[1]));
		$parsedName = array('module' => null, 'controller' => 'index', 'action' => 'index', 'extension' => $matches[1]);
		$parts = split("/", $name);
		switch (sizeof($parts))
		{
			case 3:
				$parsedName['module'] = array_shift($parts);
			case 2:
				$parsedName['controller'] = array_shift($parts);
			case 1:
				$parsedName['action'] = array_shift($parts);
		}
		
		return $parsedName;
	}
}

The main method of interest from this class is ZExt_Twig_Loader::getSource. This method is called by the Twig environment when ZExt_Twig::loadTemplate is called. This function then parses the file name passed to it and returns an array containing an array of all the lines in the template file and the time the file was last modified. The template is then parsed by the Twig template engine.

Finally to get this all working I added the following function to the bootstrap

public function _initTwigView()
{
	$twigView = new ZExt_Twig(APPLICATION_PATH, APPLICATION_PATH."/modules");
	$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper("ViewRenderer");
	$viewRenderer->setView($twigView);

	return $twigView;
}

This now means that a Twig template view will be loaded instead of the default Zend_View style template.

There are still a few aspects I have to try out with this approach such as the availability of view helpers and whether I can include other templates using the Twig engine syntax, or if I will still have to use Zend Framework helpers to achieve this. Finally I need to tidy up some of the method signatures as there are some such as the ZExt_Twig_Loader constructor that have parameters which cannot be assigned.

All of the code in this article is available on GitHub.

Any suggestions for improvements would be appreciated

So I ran the usual PEAR update command;

$ sudo pear upgrade pear

This appeared to run without any issues. But subsequently whenever I attempted to run PEAR I was greeted with the following error message;

/usr/local/bin/pear: fork: Resource temporarily unavailable

I took a look inside the offending file as it is just a simple command to run the PEAR script. It looked like this;

pear /usr/lib/php/pearcmd.php

Obviously the script was infinitely attempting to spawn itself causing the resource temporarily unavailable error. So the simple fix was to change the script to the following;

php /usr/lib/php/pearcmd.php $@

I’m not quite sure why the script changed when I upgraded but it appeared to. I figured I should pop this note up in case anyone else gets caught out, or indeed I forget and get caught out again. Any insight on why this might have happened would be appreciated.

The extension also adds a profile page to EPrints for each user. The idea of profile pages is to provide a static external facing page which the rest of the world can see. This page would include basic information about the user and the publications they have added to the repository. This effectively provides a biography of the user with regards to the repository.

One thing that we wanted to do is create pretty URLs for the user profiles of the form http://examplerepository.com/profile/. Initially we did this by making a modification to perl_lib/EPrints/Apache/Rewrite.pm but this was not the ideal situation for a plugin since this is a modification to the core code of EPrints. The problem with this approach is that if the repository administrator went on to update their core EPrints install then they would end up losing the hand made modification which is required for the plugin and they would have to add it again.

Instead we investigated creating a custom URL handler and adding it to the request handling chain using archives/ARCHIVEID/cfg/apachevhosts.conf. By doing this we won’t change any core EPrints code and all of the changes will be safe from any auto generated changes. The first thing we did was create a custom rewrite handler which took the following shape;

package EPrints::Plugin::MePrints::Apache::Rewrite;

use strict;
use warnings;

our @ISA = qw/ EPrints::Plugin /;

use EPrints::Apache::AnApache;

sub handler
{
  my( $r ) = @_;
  my $uri = $r->uri;
  my $repository_id = $r->dir_config( "EPrints_ArchiveID" );
  if( !defined $repository_id )
  {
    return DECLINED;
  }
  my $repository = EPrints::Repository->new( $repository_id );

  if( $uri =~ m! ^\/profile\/([0-9a-zA-Z]+)$ !x )
  {
    # Find the user and if found set the appropriate filename for the response object.
    # If the user is not found then don't do anything or return anything and this will
    # cause EPrints to respond with a 404 error.
  }
  else
  {
    return DECLINED;
  }
}

Next we needed to add only one line to the archves/ARCHIVEID/cfg/apachevhost.conf file;

PerlTransHandler EPrints::Plugin::MePrints::Apache::Rewrite

After a server reset we had the pretty URLs for the profile pages. This works thanks to the PerlTransHandler statement in the apachevhost.conf file. What this does is add a handler to the chain of handlers to be run. By default in EPrints there is only one handler and that is the default one. What we have done with the change above is add a handler into the chain before that. The handler method in EPrints::Plugin::MePrints::Apache::Rewrite gets called and if it gets a match for profile then it goes ahead and handles it. The “return DECLINED” tells Apache that it should move onto the next URI translation handler in the chain.

EPrints comes with the Prototype and Scriptaculous JavaScript libraries installed so we had to use these as opposed to my regular choice of jQuery. Owing to the static approach used for generating the document views in EPrints we had to inject the whole comments section of the document using AJAX. We did this by having the server generate the DOM and then sending it back to the browser which injects it into the page. This way the page can dynamically load the comments box depending on if a user is logged in or not.

Initially we managed to get the code running with Firefox and Safari but we had no joy with the code in IE. Here is some of the code that was originally used.

function sneepCommentFormInit(transport) {
  // Load in the HTML generated by the server side script
  $('ep_sneep_main').update(transport.responseText);

  // If the server sent back a form so the user can write a new comment
  // then we need to remove the old submit button and add one which is
  // attached to one of our JavaScript functions.
  $$(".ep_sneep_comment_form_container").each(function(element) {
    var submitButton = document.createElement("input");
    submitButton.writeAttribute("type", "button");
    submitButton.writeAttribute("id", "sneep_comment_submit");
    submitButton.writeAttribute("value", $("sneep_comment_submit").readAttribute("value"));
    submitButton.observe('click', sneepCommentFormSubmit);
    $("sneep_comment_submit").remove();
    element.appendChild(submitButton);
    var inputcallback = document.createElement("input");
    inputcallback.writeAttribute("type", "hidden");
    inputcallback.writeAttribute("name", "callback");
    inputcallback.writeAttribute("value", "1");
    element.appendChild(inputcallback);
  });
}

Event.observe(window, 'load', function() {
  var rm = window.location.href.match(/(https?:\/\/.*)\/(\d+)\/?/);
  if (rm != null) {
    new Ajax.Request(rm[1]+'/cgi/sneep/view_sneep?eprintid='+rm[2]+'&type=comment', {
      method: 'get',
      onCreate: function() {
        // Put up a loading message
      },
      onComplete: sneepCommentFormInit
    });
  }
});

The problem appeared to be that IE does not finish loading the updated content before attempting to add the hidden field and attaching a new submit button which calls our client side method rather than allowing the form to submit straight back to the server.

The solution we chose for this issue was to modify the initial on load function in the following way;

Event.observe(window, 'load', function() {
  var rm = window.location.href.match(/(https?:\/\/.*)\/(\d+)\/?/);
  if (rm != null) {
    new Ajax.Request(rm[1]+'/cgi/sneep/view_sneep?eprintid='+rm[2]+'&type=comment', {
      method: 'get',
      onCreate: function() {
        // Put up a loading message
      },
      onComplete: function(transport) {
        $('ep_sneep_main').update(transport.responseText+
          "<script type=\"text/javascript\">"+
          "sneepCommentFormInit();"+
          "</script>");
      }
    });
  }
});

Basically in this code we removed the code from sneepCommentFormInit() that handles the returned text and put it inside the anonymous onComplete method. We also appended some JavaScript that gets executed as soon as it is evaluated. This means that the form initialization code is only run once all of the HTML has been interpreted and loaded meaning that IE now has the submit intercept function correctly attached.