N.B. This document has been superceded by the Monk Workbench Documentation
Text from a message posted to the MONK Development list by James Chartrand on September 7, 2007:
Over the last few weeks, the McMaster group (Andrew MacDonald, Stéfan, and myself) have been evaluating the RAP (http://eclipse.org/rap) project as a platform on which a web based MONK Workbench could be built. I described RAP in a post a couple of months ago (a web based version of the Eclipse workbench) and Andrew yesterday posted some screenshots of MONK components running in RAP (in a web browser), including a Collection Browser and a Chunk Browser, both of which draw live data from the MONK web services. The code for those components is written in SWT, the Standard Widget Toolkit (http://www.eclipse.org/swt/), which is the same Java widget set used by Eclipse. Eclipse converts SWT Java code to native operating system calls, RAP converts the same Java code to a combination of AJAX and server side code. And so, here's the somewhat amazing part, I was able to take Andrew's components, and with no change to the gui part of the code (I only had to delete three high level RAP specific classes), create a plugin for the desktop Eclipse workbench, which – amazingly – worked immediately in my desktop Eclipse, drawing the same live data from the MONK web services. For those of you who use Eclipse, or have Eclipse installed, I've attached a jar file which can be dropped into the plugins directory of your Eclipse application (see instructions below) after which you can open a Collection Browsing view and Chunk Browsing view in your Eclipse editor. Again, these views are drawing live data from the MONK web services.
Many of you are, I think, familiar with Eclipse (http://eclipse.org), which was originally developed as an IDE (Integrated Development Environment) for Java Development – in other words, an environment in which Java programmers can write and debug Java code. Eclipse has since become a very modular and extensible platform that can be used for a variety of purposes, including xml editing, annotation (see John Bradley's Pliny project - http://pliny.cch.kcl.ac.uk/), etc. An Eclipse user can create a very personalized workbench by mixing and matching 'plugins' which are essentially little applications that run within Eclipse. A user could have an xml editor in one pane, a file browser in another pane, an SVN repository browser in another pane, the Pliny annotation tool in another, a standard text editor in yet another.
And so..... an 'advanced' MONK workbench could be built with Eclipse, where different MONK components could be written as plugins, and some subset of the plugins could be delivered over the web through RAP. Among the plugins could be for example, a Collection/Chunk browser plugin, a feature selection plugin, different visualization plugins, a set of WordHoard plugins, FeatureLens plugins, Nora plugins, etc. By working against the Eclipse plugin framework and the OSGi component framework that Eclipse uses internally, each of the differrent projects (Nora, FeatureLens, WordHoard, etc.) could work at least somewhat independently to create their own set of specialized plugins which could then work together with the other MONK plugins. Standard plugins like collection browsing would of course be shared by all. Although Eclipse uses SWT for the UI, apparently Java Swing components can run within Eclipse, so existing Swing code could potentially be reused. That would have to be confirmed though.
Plugins communicate through 'extension points' and in MONK's case extension points could be used to define a set of events that would enable the different MONK components to communicate with each other. The idea here is that as new plugins are added they can take advantage of events published by other existing components, for example, a 'chunk selected' event, without having to modify the code of the existing plugin. Further, because the Eclipse plugin framework and extension point framework are very well developed and documented, it makes it much easier to coordinate development between the different groups that make up MONK. Each group can work fairly autonomously, and can achieve interoperability by making sure their components work in Eclipse as plugins and by publishing and subscribing to MONK events using the extension point framework. Note that Eclipse even supplies an extension/extension point editor, and in fact provides visual editors for most tasks, including creating plugins, packaging plugins for distribution, creating a full blown Eclipse distribution, etc.
This last point is important, that a full blown Eclipse distribution can be easily created. We could create an installable application with a preset selection of MONK components, and the end user will never (probably) know it is an Eclipse application. More importantly, they don't have to install Eclipse and then manually pull in plugins. They can, however, certainly pull in any plugins they might find or already know about, like say a news reading plugin.
Another advantage to using Eclipse, then, is that MONK could immediately make use of existing Eclipse plugins that work alongside the MONK specific components. For example, one scenario could see a user browse the MONK collection view to select a text, which they could then drag into the Eclipse resource view (components in Eclipse are called views) where it would be saved to their local file system. The resource view part is provided by Eclipse. They could then right click the file in the resource view to open the file in an xml plugin (Oxygen for example), make changes to the file in the xml editor, save it back to their local directory, and then possibly, depending on what rights they have, upload the file back to the MONK repository (Fedora for example) by dragging the file into the repository view. The point is that the user has used components provided by both MONK and Eclipse. Another view in the MONK workbench could make use of a visualization plugin like http://www.eclipse.org/mylyn/zest.php. Another view could enable feature selection, another analytics.
On the web side, a subset of the Eclipse components could be delivered over the web via RAP. Admittedly, it would not be easy to achieve the same visual effects with RAP as with standard AJAX. That is in part because the 1.0 version of RAP is not due out until the end of the month, and so documentation is severly lacking, making it very difficult to evaluate how hard it would be to add custom AJAX widgets. Also though, because RAP is a split client side/server side solution, coordinating between the client (browser) and the server would be harder if a lot of funky effects (drag and drop) were happening in the browser. That said, the RAP people do plan to support, for example, drag and drop, but not until 2008 at the earliest. On the other hand, the ability to develop once though for both the web and the desktop might make it worthwhile to spend the time to create the custom funky components MONK would require. There would also certainly be components that ran in Eclipse, like visualization components, that could never run
in the web browser, but that is one reason why the desktop version is 'advanced'.
There is also a whole other discussion about storing work locally – using a desktop application would simplify that.
The jar file for the plugin:
https://apps.lis.uiuc.edu/wiki/download/attachments/31767/org.monkproject.nora.1.0.0.jar
Instructions to install the MONK plugin:
- Shutdown Eclipse
- Once you've got the jar, put it into your eclipse plugin directory for example, Applications/eclipse/plugins
- Start Eclipse
and then to use the plugin:
- in Eclipse, choose Window, Show View, Other, MonkEclipse (which is a folder), and then
select both the 'Collections', and 'Chunk Viewer'. - the views will open somewhere in your workspace. find them and resize them as needed.
- you can now browse the collections and their docs and chunks. everything is coming
from the MONK web services, so all data is live.
