This page last changed on Oct 19, 2007 by sgs@mcmaster.ca.


N.B. This document has been superceded by the Monk Workbench Documentation

MonkBench Client-Side Workbench Architecture

The MonkBench is meant as a very light-weight, client-side architecture for the Monk environment. Basically developers extend a base component class (Monk.component.Component) and instances of thoses classes register themselves with a component manager. The component manager is responsible for notifying each of the components of events – components decide locally how to handle events (or ignore them). Other characteristics:

  • monk type events are managed by components rather than individual widgets
  • components can make use of whatever JS library or web technology (Flash, Applet, etc.) they wish

This is a very simple and light solution, which has pros and cons: it's fairly easy to develop new components and plug them into the system, but we the environment may eventually become too complex for such a simple solution. In any case, here's an example of some code:

/**
 * @class Monk.component.TreeCollectionsBrowserComponent
 * @extends Monk.component.Collections
 * This class allows for browing collections and loading a workset.
 */
Monk.component.TreeCollectionsBrowserComponent = function(args) {
	Monk.component.TreeCollectionsBrowserComponent.superclass.constructor.call(this, args);
}

Workbench.extend(Monk.component.TreeCollectionsBrowserComponent, Monk.component.Collections, {

	label : "Tree Collections Browser",
	description : "This Component allows for browing collections and loading a workset",
				
	handle : function(monkEvent, data){

		// check typed events
		if (monkEvent.instanceOf(Monk.event.CollectionsMetaDataHierarchyLoaded)) {
			// do something with collections data
		}
	}
});
Document generated by Confluence on Apr 19, 2009 15:04