by David Huynh, July 21, 2003

Mo-net: (www.m-w.com)

Monet is the new user interface framework of Haystack, still to be written. It makes extensive use of Mystique's dynamism to keep the UI up-to-date with respect to the underlying data model. Its core features include:

1. Unified paradigm for presentation, including screen display and printing
2. XHTML (subset) and SVG UI element library and extension
3. Support for internationalization
4. Uniformity in direct manipulation and editing (hopefully including uniform zooming and scrolling)
5. Multiple window interface

Why internationalization (I18N)? While I18N itself is not a research issue, forcing ourselves to think about I18N while building Haystack makes us reflect on various issues that arise because of I18N. For example, a resource may have different titles in different languages (e.g. Friday in English and vendredi in French): how do we model titles that are language sensitive?

Basics

When a programmer wants to display some information to the user, the programmer needs to specify:

1. What to present (e.g. one or more items, zero or more relationships)
2. How to present (e.g. include an icon, emphasize the text, use a particular layout, use a particular UI element)
3. Optional contextual information (e.g. UI behaviors, font settings)
4. The presentation environment, like a graphics context (encapsulating details about printer or screen display, etc.)

To make a presentation of a single item, the programmer calls:

The implementation of the function monet:present is as follows:

With the view producing function known, monet:present attempts to retrieve past settings that apply to all invocations of that view producing function. These settings are stored in an information closure bound to the variable classSettings. If no past settings are found, a new closure is created.

monet:present also attempts to retrieve past settings that apply only to the invocations of the view producing function on the given specifications. These settings are also stored in an information closure, bound to the variable instanceSettings. A new closure is created if no past instance settings are found.

A new context is set that encapsulates all past settings as well as the optional contextual information and the current context. The view producing function is then called with a layered RDF data access point wrapping the base RDF information source, the view request specifications, and the new context.

The view producing function is supposed to return 3 results: new instance settings, new class settings, and settings that it doesn't understand and that should be propagated upward for persistence.

View Producers

A sample view producing function looks something like this:

First, the function retrieves the author of the email. Next, the function creates 3 curried functions whose jobs are to present the icon, subject, and author of the email, respectively. Note that the 2 calls to monet:present return curried functions rather than results because they are not provided the parameter named monet:PresentationEnvironment. Likewise, the call to the function monetUtil:presentIcon also returns a curried function.

monet:present is called once again, this time to present an XHTML fragment. But first, the XHTML fragment is substituted with the 3 curried functions so that the presentations (i.e. views) ultimately produced by these 3 functions fit into the XHTML fragment template. This final call to monet:present is given a presentation environment so that the presentation can actually be rendered. The propagated settings returned from monet:present are assumed to be class settings.

The view producing function responsible for presenting XHTML fragments calls the substituted curried functions with a presentation environment so that the curried functions can render their stuff.

There are several improvements with this new paradigm for writing view producing functions:

1. View producing functions are written in a very imperative fashion. This paradigm is, in my opinion, more familiar to naive programmers than the declarative fashion in which slides et. al. are written.
2. Monet does make explicit the distinction between instance settings and class settings, and it also handles the persistence of these settings on behalf of UI programmers.
3. There is no longer a need to use data sources explicitly--dynamism is already a core feature of Mystique.
4. View producing functions and monet:present do not make assumptions about the presentation environment: that means we can substitute a different presentation environment (e.g. a printing presentation environment, an HTML output p.e.) and benefit from this whole presentation architecture.

In case you think that the sample view producing function above is long, we can always shorten it as follows:

Multi-View Producers

Often we want to present several items together, arranged in some desired fashion. This need has been satisfied by layout managers in Ozone. Monet takes an approach not too different from that used for presenting just one item. To present several items, encapsulate them in a Collection object and call monet:presentMany:

Writing a view producing function for presenting several items is almost like writing a function for presenting one item:

Empty Collections

In the case that the collection in the previous example is empty, we might decide to show a special message saying "No items in this collection". This can be done in two ways. First, the multi-view producing function can be made smarter with a test:

Sorting

We can set the sorting order in :presentMeeting as follows:

Internationalization

So far we have embedded XHTML fragments inside the code of view producing functions. However, because these XHTML fragments have been encoded as templates with substitutions in the form {%number}, we can extract these XHTML fragments out for internationalization. So, instead of calling:

The function monet:findResource is as follows:

Of course, mail:summaryViewTemplate has to have some metadata somewhere, most probably in the same file that uses it:

Input Methods

One of the major issues of internationalization involves input methods--mechanisms for inputting characters not available immediately on the keyboard. Java does have a framework for implementing and using input methods. Unfortunately, this framework is tied to AWT. We will have to create our own input method framework.

Help

Context Menus and Drag and Drop

Mixing XHTML and SVG

Miscellaneous

Migration Plan