Melati and JTemplater

Introduction

At present, Melati qua web application library is quite closely tied to WebMacro (although POEM is not). In future, however, we want to use JTemplater. The changeover seems a good opportunity to reassess the interaction between Melati, POEM and the templating subsystem, and to make it a little more abstract so that we can allow people to change between (say) WebMacro and JTemplater with as little fuss as possible.

Inventory

Melati currently does the following jobs relating to WebMacro:

Enhancement of WMServlet

This is what MelatiServlet and its parent MelatiWMServlet do: (There is no real point to the separation; it's just that the latter is a hacked version of WMServlet.)

These are all things we will still want to provide, but independently of WebMacro. What should MelatiServlet look like, then?

Extraction of current object

This is done between Melati and MelatiServlet.melatiContext. It's useful to structure many web applications around the notion of "the object on which the present HTTP request is operating, and the action we want to do with it".

Enhancement of variable expansion

This is what our hacked org.webmacro.engine.Variable does.

How does this relate to JTemplater? Probably we want to provide two behaviours for JTemplater, at the level of the $(...) expression in which the exception occurs: just terminate expansion and throw the exception, or interpolate a representation the exception instead of the result of the expression. But it would be nice if the latter could do some context-sensitive escaping.

$renderBody(obj.getFoo())

Markup language support

This is what the *MarkupLanguage classes do:

Text escaping

Escaping ("rendering") of text according to the conventions of the language. In fact there are several different kinds of escaping to be done in HTML, depending on the context:

Doc body, attribute value "
Javascript value\042
URL=22

Exception rendering

Rendering of exceptions for display to the user, where the VariableExceptionHandler returns them to be displayed rather than simply throwing them out to terminate expansion. Again, this is context-dependent:

Doc body <I>error!</I>
Attribute value (e.g. input box content) [error!]

As of 21/07/2000, the representation of the exception is determined from a sub-template or "templet". The MarkupLanguage tries to load a WebMacro template (through the servlet's Broker) from a directory named after the markup language. The filename of the template is taken at first to be the package-qualified class name of the exception with .wm appended; if that doesn't exist, it tries the superclass, and so on until it finds java.lang.Exception.wm, which just does

[$ml.rendered($exception.toString())]

The templet is expanded to a string against a specially constructed Context, and the string is returned to WebMacro for interpolation into the parent template. It would obviously be nice if the templet could be expanded directly to the output stream, so that the extra buffering could be avoided.

Smart field handling

Field rendering

Rendering of POEM Fields, i.e. values wrapped up with PoemTypes, for display. (N.B. do we need a PoemTypedValue which is like a Field but doesn't have a name? The name isn't needed here, only for rendering input controls.)

The functionality is: compute the field's localised ‘cooked string’ representation; size-limit it; escape it for the doc-body context.

Persistent rendering

Rendering of POEM Persistents, which just means calling up their localised displayString and rendering that in the doc-body context.

Input control rendering

Rendering of an input box, dropdown, etc. appropriate for entering the value of a POEM Field. This has always used a ‘templet’ mechanism similar to that used for exceptions: a markup language-specific directory is searched for a templet named after the PoemType of the field, except that the templet name can also be set explicitly in the field's getRenderInfo property (ultimately, in the admin interface).

The name of the field is prefixed with field_ (the prefixing is done in each templet individually, which doesn't seem right). When the returning form is interpreted, Melati.extractFields knows to put that prefix on the field names of the Persistent into which things are going.

General observations

Desirable features for cleaner version

The idea of making ‘Melati’ essentially a utility object ($melati) accessible within templates still seems a good one. However,

Generalising from that last point,