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

Monk WorkBench (a.k.a. Webclipse)

• see also: Monk Workbench Development
• see also: Monk Standalone Eclipse Workbench

We have discussed the need for an open-ended, modular architecture for the Monk environment, something able to accommodate various types of components in a web-based context (examples of components might include the Nora interface, FeatureLens and XPathFinder). One of the most successful examples of such a platform on the desktop is the Eclipse IDE. While it would be unreasonable to expect us to reproduce something as sophisticated as Eclipse, and while it's important to keep in mind that Eclipse is primarily a development environment and we're looking for an analytic environment, Eclipse may serve as a very useful model for developing a flexible and modular Monk platform. In particular, Eclipse defines useful concepts of Features, Perspectives and Views.

Objectives

• for users:
  • try to provide some consistency to the interface
• for developers:
  • leverage an existing workbench platform (no need to duplicate common interface elements
  • leverage other tools through a compatible framework

Features

From Eclipse documentation:

On disk, an Eclipse based product is structured as a collection of plug-ins. Each plug-in contains the code that provides some of the product's functionality. The code and other files for a plug-in are installed on the local computer, and get activated automatically as required. A product's plug-ins are grouped together into features. A feature is the smallest unit of separately downloadable and installable functionality.

Features are collections of plugins and plugins provide the functionality of the workbench. To use the Nora OL interface as an example, Nora would be the feature that groups together a set of plugins, including the collections browser, the document rating mechanism, and the tabular data viewer.

Dynamically loading plugins is obviously trickier in a web-based environment than on the desktop, in part because of Javascript security restrictions. One possibility would be to structure features as a set of scripts to be loaded into the hosting page. A more dynamic mechanism would be to have a manager script that is able to load plugin scripts and resources as defined and needed. A good example of this dynamic behaviour can be seen with the TinyMCE HTML Editor; compare the source code of two examples, the examples and full editors.

Perspectives

From Eclipse documentation:

Each Workbench window contains one or more perspectives. A perspective defines the initial set and layout of views in the Workbench window. Within the window, each perspective shares the same set of editors. Each perspective provides a set of functionality aimed at accomplishing a specific type of task or works with specific types of resources.... Perspectives control what appears in certain menus and toolbars. They define visible action sets, which you can change to customize a perspective.

Perspectives can have a fairly close relationship with Plugins (e.g. there could be a data mining plugin and a data mining perspective), but perspectives make it possible to share components across plugins. Plugins are the code that provides certain functionality whereas perspectives are different interfaces to functionality in one or more plugins.

Views

From Eclipse Documentation:

Views support editors and provide alternative presentations as well as ways to navigate the information in your Workbench. For example, the Navigator and other navigation views display projects and other resources that you are working with. Views also have their own menus. To open the menu for a view, click the icon at the left end of the view's title bar. Some views also have their own toolbars. The actions represented by buttons on view toolbars only affect the items within that view. A view might appear by itself, or stacked with other views in a tabbed notebook. You can change the layout of a perspective by opening and closing views and by docking them in different positions in the Workbench window.

The following are some of the essential qualities of views:

• views can exist in several perspectives
• changes in views can cause other views to update automatically
• views can be automatically opened if needed (when triggered by other views)
• views can be moved to different locations
• views can be closed or detached to be stand-alone windows
• views can be minimised and maximised
• a view is practically composed of a main frame and a tab
• the active view determines the content of the file menu, the toolbar(s) and the status bar

Architecture

Building an interface for the web that looks somewhat like Eclipse will probably be relatively easy compared to making the interface behave like Eclipse, i.e. where Views can be interoperable and core functionality is standardised. It would be well worth having a much closer look at the Eclipse platform code. In the meantime , one of the critical things to work out is an event model for the interface. Assuming the Workbench is a single HTML page composed of dynamically generated DHTML components (as opposed to, say, frames), one approach would be to have all events that occur within a view (that is a plugin in a feature) reported first to view, then to a feature manager (which can dispatch events to other open views within the feature) and then to workbench manager (which can dispatch events to any views that aren't part of the feature but that are compatible). Much planning is needed here...

Publish/Subscribe

The YUI library provides a publish/subscribe framework:

http://developer.yahoo.com/yui/event/

that could be useful. A simple approach could be to have new views include a javascript function (or functions) that the view would like invoked (fired) in response to certain events. At its simplest we could even require that the view includes the javascript YUI code to subscribe to the events. This would require of course, though, that the developer of the view know what events can be subscribed, and so perhaps it would be better to instead just put all publish/subscribe info in a single configuration file that would not only list all available events (and their publishers) but also all subscribers. We'd then have some code somewhere that would generate the javascript YUI subscriptions and publications (notifications). The view developer would still have to write the javascript functions that they'd like fired (we actually want to allow the developer to write these functions for maxiumum flexibility.) The javascript functions could then do things like make AJAX calls to the server to update the view state (for example, if a new collection was selected in the collection browser view, a 'subscribing' collection info view might then need to retrieve the new collection information.)

jMaki Events

https://ajax.dev.java.net/publishsubscribe.html

jMaki provides a publish/subscribe event system. Using this system, multiple widgets/views can subscribe to an event (or topic, as it is called in jMaki). In addition, you can specify what information gets sent with the event message, including javascript objects. The topics that a widget subscribes to are declared in the widget code itself, along with the custom handlers for a particular topic. Subscribers can use wildcards when determining topic names of interest, allowing for a widget to be aware of all "save" events, for example.

jMaki also has the concept of Glue, which is a separate javascript file in which you can add event handlers not tied to widgets, set timers which will periodically publish an event or call a function, and add listeners which forward one topic to several other topics (more info here: https://ajax.dev.java.net/glue.html).

The jMaki event model would be useful in any situation where you have distinct components/widgets that you want to communicate with each other, but without tying them together explicitly. In this way, widgets can be swapped in an application without making drastic changes to the underlying code. An example of this is included in the jMaki samples, wherein a location search can be sent to either a Yahoo or Google Maps widget, with the only code change being the widget name in the index file.

Related Links

A Tibco presentation of a commercial product that claims to provide in-browser event notification between components:

http://www.tibco.com/devnet/resources/gi/videos/ajaxportlets/part4/index.html

A few sketchy thoughts on the Webclipse stuff. Abstracting from the interface ------------------------------ As Stefan said above there are several advantages to the Webclipse idea, and specifically from the developers perspective: leverage an existing workbench platform (no need to duplicate common interface elements) leverage other tools through a compatible framework If we additionally assume that a Webclipse framework would use configuration files for things like defining the views that make up a perspective, and for defining the relationships between views as publishers/subscribers, then another benefit would be that we are in a better position to accomodate multiple (and future) interface implementations (which I still think is extremely important) since we'll have abstracted some of the interface details from the actual implementation. A sketchy publish/subscribe xml config: <events> <publications> <publisher name="CollectionBrowser"> <publication name="collectionSelection"> <args> <arg type="string" name="collectionName">myCollection</arg> <arg>...</arg> </args> </publication> <publication name="collectionViewClosed"> .... </publication> </publisher> <publisher name="FeatureSelector"> .... </publisher> </publications> <subscriptions> <subscriber name="featureSelector"> could here subscribe to all publications by a given publisher or to unique publications <publication> or <publisher> </subscriber> </subscriptions> </events> For a javascript based interface, we could translate this config doc into reality by generating YUI Event Utility custom event code that would manage the subscriptions and publications (http://developer.yahoo.com/yui/event/). There are of course complications like managing the order of simultaneous publications or weird effects like one publication causing a subscriber to publish another event that might trigger the first publication so the cycle never ends. A good reason for using an existing event handling framework if the framework already deals with some of these issues. And of course, if UI config files were used (like XUL or LZX or something - see http://en.wikipedia.org/wiki/User_interface_markup_language) even better but that seems hard when we want to take advantage of new browser functionality, etc. Server based vs. in-browser event notification ---------------------------------------------- A web based Eclipse-like framework already exists to some extent: a web portal (Cocoon, Jetspeed, OpenPortal, etc. - see http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view) Specifications like JSR-168 or JSR-286 or WSRP v1 and v2 (http://en.wikipedia.org/wiki/WSRP) provide a means to wire together different views (portlets) and, especially with JSR-286a modified JSR-168, or WSRPv2, a means for views (portlets) to communicate with each other. However, a portal (at least the ones I know) assume that the entire web page is rebuilt for each request, and that the portlets communicate with each other on the server as each page request is processed, e.g., during a page request, a collection browsing portlet might receive a request to show a new collection, and so the portlet (or rather the portal container) would notify any subscribing portlets so that the subscribing portlets could rebuild their view before the full page goes back to the browser. Stéfan's in-browser notification, on the other hand, assumes that a view will notify other subscribing views directly in the browser and then leave it up to the other views to refresh their state by making Ajax calls to the server (or to distributed servers). I think we found that this use of web services worked pretty well with the NORA OpenLaszlo demo. In any case, some advantages of the portal and Sinclair models, respectively: advantages to notifying on server (aka portal model): don't have to track publications/subscriptions in browser (although we'd still have to track them on server, but that seems potentially easier, since we can use the session on the server) - A tool like the Yahoo Event Utility would appear to simplify in-browser notification, but it might make it harder for us to maintain a correspondence between the server state and the browser state, which may not be a big deal, and in fact might be an advantage (if the server tracks no state). easier to notify any subscribers that might not appear within the browser at the moment, but would still like to be notified. would ultimately probably minimize browser trips since there would be one trip to the server rather than a bunch of trips (via Ajax) by each component (view) to update themselves after receiving event notification. existing JSR 168 portlets could be integrated into MONK if MONK used a portal model, so portlets from SUN like their 'notes' portlet or perhaps more importantly stuff from SAKAI or uPortal (although I'm not sure how far SAKAI has gone with JSR-168). If MONK views were made JSR 168 compliant that would also possibly allow MONK portlets to be more easily incorporated into portals like SAKAI, uPortal, etc. existing documentation/procedures for producing new portlets (e.g. http://community.java.net/portlet/) Even though we might not want to use the portal based (server-side) event notifiction, it might be worthwile looking at existing portal implementations as a means to initially (when the user first requests the workbench) generate and organize the views in a given perspective and possibly save a user's preferred view layout. A portal like Light might make sense: https://light.dev.java.net/ advantages to notifying in browser (aka Sinclair model): faster user experience if some subscribing views can update themselves without requiring a trip to the server, or can use asynchronous calls. might better match the MONK web services model, since even with the NORA demo we found it easier to have individual components make calls to the web services via Ajax, rather than, for example, have the server build the entire page, making calls to all various web services from the server and then building the entire page in one go. This brings up the authentication question though (see next). could make a distributed model a bit easier if the views make calls to different servers. allows for a very flexible GUI because bits and pieces can be assembled relatively easily (we hope) since we are essentially leaving each view to manage its own state (via Ajax calls). Authentication -------------- Just as we found with NORA, authentication will be an issue. Providing access to protected resources could be problematic, but we were able to use BASIC authentication with NORA between OL and Acegi. We could also potentially do something like http://developer.yahoo.com/auth/authcalls.html if need be. Posted by chartra@mcmaster.ca at Jul 05, 2007 11:34