How to write plugins
Write a Plugin!
The plugin system for EPrints 3 has been developed to make it easy and share the most common extensions to the code without having to hack the core system (and causing yourself problems with upgrades etc.)
When the system loads, it automatically loads all modules in the perl_lib/EPrints/Plugin/ directory, so for simple plugins you just drop them in that directory and you're done!
When a plugin is loaded it has a registration method which is called which tells the core EPrints system what this plugin does. EPrints then makes it available as appropriate.
Clever plugins can detect features they need and adapt to use the tools available, or disable themselves if they are missing required tools (rather than crash the system). Some specialised plugins are disabled in their default state and must be enabled in the repository configuration.
Another cool thing is that plugins are Perl Objects, which means you can subclass them. Here's an real-world example: We have a research group which uses BibTeX but over the years standardised within the group on an extra field. This is not a valid bibtex field, but are essential to their working because they have ancient and essential scripts which depend on it. To handle this we can subclass the default BibTeX Export plugin and override a single method (the data mapping one). We then just call the original parent plugins mapping method to do all the heavy lifting, then just add our non-standard extra field. Total code required: less than one screen. Number of happy researchers: none (they are never satisfied and will just demand the moon on the stick because you've already given them this nice new feature), but number of researchers able to get their work done: lots. Don't believe me? look here!
- See also Extension Packages for how to add configuration and resource files to plugins.
Types of Plugin
There are a number of different kinds of plugin for EPrints...
These are used to export the data in a variety of formats. They are quite easy to write, once you get started.
These are used to import data into a repository. They can take datafiles directly, or they can take an ID of a record that can be retrieved in a known way, or a URL of a file, or... whatever.
These are a bit trickier to write than export plugins as parsing data is harder than just "print"ing it, but they are still reasonably straight forward.
These handle (almost) all the user interface screens. Pages like "Review" and "Profile" are just built-in plugins. You can add your own very easily.
Examples you could create...
- Birds Eye View - a view of various statistics on the database, all in one page.
- Spellchecking Tab - an additional tab in the item control page which checks the spelling on certain fields.
- Bulk Delete tool - a tool which takes a list of eprintid's and deletes them all in a fell swoop.
Look at the existing Screen Plugins for an idea of how they work. They can be very simple.
Input Component Plugin
These handle how the workflow components are rendered. Built in components include the default (one field) component, the multiple fields component, the upload component, the subject component (which does pretty things to a field of type "subject") and the XHTML component. You can add your own or sub-class existing ones.
These are used for two things, currently.
- Converting the full text of documents into utf-8 text for search indexing
- Converting images and pdfs into thumbnails and previews
Some examples you could create:
- RTF to utf-8 to allow rich text documents to be indexed.
- Powerpoint to Thumbnail to allow thumbnail and previews of powerpoint slides
- Video to Thumbnail/Preview to make a still preview of a video file.