An Eclipse RCP digitization wiki with e4 and Scala

We have reached the first milestone of a new project I have been working on since November. The goal of the project (which is funded by the DFG) is to create a wiki for collaboratively improving the digitization of the Romansch Chrestomathy, a collection of Romansch texts.

I think the domain of this project is very interesting, as it not only aims at improving access to cultural assets, but also takes the community wiki approach, which leads to a situation that is probably not the most common case in academic software development: users are part of the plan.

But perhaps even more, I’m excited about the technical parts of the project, as we use both Scala for the core, non-UI components and e4 for the UI.

Our first milestone for the initial beta (which we plan to release in summer) provides a basic local, single-user implementation of our system. It features basic search and page selection, editing and persistence, word-based edit history and highlighting of the currently selected word in the original scan.

Screenshot

As expected, combining two cutting edge technologies (Scala 2.8 and e4) does cause some inconveniences (e.g. I currently can’t develop the Scala and the e4 code in the same Eclipse instance, as the Scala IDE for Eclipse does not yet support Helios and e4 won’t run on Galileo).

But once I had a proper Ant build system in place (compile Scala sources, deploy as Jars into the e4 workspace, etc.), I was amazed about the concise code base we were able to build both for the backend and the UI with this approach.

To give some examples of what I liked about developing using Scala and e4 I’ve picked out a few lines from both sides of the current (not very large) code base.

On the Scala side, I really liked having features like case classes, XML support, and concise anonymous functions.

For instance, the XML serialization method of a Page defines that the full structure of the XML is to be filled with the XML representation of each Word of the Page:

def toXml = <page> { words.toList.map(_.toXml) } </page>

We also needed a method to get a simple text representation of the Page, made only of the most recent form of each Word:

def toText = ("" /: words) (_ + " " + _.history.top.form)

And to implement a simple full text search for collecting pages in which the edit history of a Word contains the given term, I checked each Page like this:

page.words.exists(_.history.exists(_.form contains term))

On the e4 side, the whole development experience feels much more lightweight and modern than developing with Eclipse 3 thanks to e4 features like the Toolkit Workbench Model, dependency injection and CSS styling.

For instance, the view at the bottom of the application (showing the original scan) needs to listen to the selection of the Page in the top view (showing pages matching the search term). To listen to the selection of pages, the view defines a method with the following signature:

@Inject public void setSelection(@Optional @Named(SELECTION) Page page)

At the same time, the bottom view also needs to react to the selection of a word in the central edit view, in order to highlight the particular section in the page. Again, we define that we want to get called if a word is selected somewhere (which is represented by a Text widget here):

@Inject public void setSelection(@Optional @Named(SELECTION) Text word)

And I think it’s really awesome to be able to specify font style and size (and even gradients) for the Text widgets used in the edit view with CSS:

Text { font: Times 14px; background-color: #e8e8e8 #cccccc 60%; }

With the information on how the views are put together in the TM and the CSS file containing the styling information, the remaining UI code feels much lighter than before: there are basically just a few view classes and handlers, communicating loosely via DI and the TM.

So for me, combining Scala and e4 is a great new way to write a Java desktop app! And hopefully more… Our plans for the beta include multi-user support and web deployment with RAP – some challenges for sure, but with the great start I had into e4 development, I’m very confident it will work out!

We have been working on this in public from the start (after all, it’s publicly funded), so you can take a closer look at the code or check out this very early state of the application on GitHub.


About this entry