Martin Paul Eve bio photo

Martin Paul Eve

Professor of Literature, Technology and Publishing at Birkbeck, University of London

Email Books Twitter Google+ Github Stackoverflow MLA CORE Institutional Repo ORCID ID   ORCID iD

Email Updates

Part of the work for our grant to Birkbeck from the Andrew W. Mellon Foundation is to create a software project that uses the annotation backend of to allow others to translate scholarly works (and for a user base to then be able to view those translations). Essentially, we want the sentence keying tech. to key to foreign languages.

I’ll be honest: so far, we’ve spent a long time trying to learn and understand all the technologies used by so that our project can be a neat, self-contained, and non-repetitive codebase that draws in and overrides components of the annotation project. The project uses a dizzying number of technologies: pyramid, Annotator.js, coffeescript, javascript, jquery, python, AngularJS, node.js, browserify, postgres, nsqd, postgres, elasticsearch, redis, rabbitmq, and others. Because is a rapidly transforming project, we also have had to fix upon a certain version (and give instructions to revert the git tree of to the version we are using).

The challenge I had today, which I wanted to document here, was that I wanted to write-in a plugin for the version of annotator.js that would select a page, sentence-by-sentence, as part of our user interface. To achieve this, I spent quite some time today wrestling with the way that pyramid interacts with browserify in order to handle assets.yaml files spread across multiple projects.

The first thing I noted is that assets set to output in h: (that is, prefixed namespace addresses seem to use the assets file from h, regardless of whether you have set additional depends in the assets file in annotran. I had, therefore, to copy + re-map the main.js loader file so that it was within annotran and so that my new, additional plugins were handled.

Secondly, plugins to’s version/use of Annotator.js (such as TextSelection) are activated by a constructor call that takes place in So, again, for now at least, I have duplicated and remapped its requires to a relative (“../”)-type path. This affords us a space in which we can put constructor calls to various plugins that we might want to load and now gives a full environment for writing and loading plugins to Annotator from within annotran with minimal code duplication.

That said, it would be really nice if was a bit more, well, “hooky”. What I mean by this is that although Pyramid allows asset overriding, it continues to cause us a whole world of pain every time we need to build in new features. The documentation on extending/re-using the project is also a work in progress at the moment, so we are just having to work things out as we go. I hope to continue to document this experience.