Architecture of the UBOS Mesh User Interface
- 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
http://example.com/foo), 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
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 (
namebeing 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 (
timestampis 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 Handlebars.java 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
which then can be decoded by the HTTP Shell.
For more complex requirements, the HTTP Shell can alternatively (or additionally)
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?
How do we best render traveling back in time and the operations moving back and forth? (issue).