Architecture of the UBOS Mesh User Interface


Base principles

There is a one-to-one mapping between MeshObjects in the primary MeshBase and the URLs accessed by the user:
The primary UBOS Mesh webapp runs at some root URL (say, and if a MeshObject has MeshObjectIdentifier bar, it can be accessed at
A given MeshObject can be rendered in more than one way:
Each piece of code that implements one of those renderings we call a Viewlet. A Viewlet can typically render one type of MeshObject, but there are some that are more flexible, such as the PropertyViewlet, which inspects the MeshObject at run-time and shows what it finds dynamically.
Which of the applicable Viewlets is chosen depends on context:
In the current implementation, Viewlets provide a “matching score” to the Viewlet framework for a given candidate MeshObject and the framework picks the best match. The user can override this, which is implemented by adding a URL parameter (?vl=<name> with name being the name of the Viewlet). HTML rendering the set of available alternatives is automatically generated by default. In the future, we can be smarter (user preferences, smart context dependency etc)
Any Viewlet for a given subject MeshObject should always show links to all of its neighbor MeshObjects:
This way, the user can always continue navigating and understand how a given piece of data relates to all other pieces of data
The present is the default, but the user can travel back in history:
The base URL of a MeshObject refers to the MeshObject in the primary MeshBase. By appending a parameter to the URL (when=<timestamp> where timestamp is the time in history we are looking for), a previous version (or the same, if it hasn’t changed) of the MeshObject is rendered.
Traversal from a historical MeshObject stays at that time in history:
If a Viewlet currently renders an old version of its subject MeshObject, clicking on a link to a related MeshObject will render that related MeshObject at the same time in history. (Note: This may not be implemented fully at this point.)

Handlebars-based implementation (current)


HTML is created through the framework, supported by a library of UBOS Mesh-specific convenience “Helpers” (aka custom tags.)

##@ Input, handlers and the HTTP Shell

The “HTTP Shell” is run whenever the default UBOS Mesh web app receives an HTTP POST request, which it then decodes based on certain conventions.

Experience has shown that many Viewlets’ data update requirements can be supported simply by following a convention for how to name HTML input fields, which then can be decoded by the HTTP Shell.

For more complex requirements, the HTTP Shell can alternatively (or additionally) run developer-provided Handlers.

Open challenges

  • How does a rich client-side UI (e.g. React) fit into this, exactly? What does the Viewlet framework look like in React? (Idea: do the Viewlet ranking on the server, and provide it to the React client, which then is responsible for running the right Viewlet.

  • Can we come up with a uniform “gesture language” for relating and unrelating MeshObjects?

  • Can we come up with a consistent way of showing MeshObjects that are related to the current subject MeshObject?

  • How do we best render traveling back in time and the operations moving back and forth? (issue).