The server-side processing of CaptainCasa internally uses Java Server Faces (JSF). ...but: we do this in a non-traditional way, which has nothing to do with the classical JSF rendering of HTML pages.
CaptainCasa is based on a JavaScript program that runs in the browser-client and that generically renders layouts coming from the server and passes back user events. From topology point of view, the browser-client is a “Single Page Application” - even though this term might be a bit misleading, because the application processing clearly is on server-side...
This document describes the way JSF is used by CaptainCasa.
First of all: why did we (in 2007) decide to user Java Server Faces?
The response is quite simple: JSF is the one and only Java Standard (JEE) for server-side interaction processing! And, more important: even though JSF was created to serve scenarios, which traditionally render HTML directly, it was always treated as generic framework which is a bridge between any type of client-side rendering processing and server-side application processing. It is not bound to HTML, but from beginning on was designed to serve other UI-channels as well.
Do we use all aspects of JSF? No! Many of them are not suitable. E.g. all the navigation concepts are not useful for modern dialogs. But there are some core useful functions which exactly fit our requirements:
General request/response processing
Component tree processing
Expression management for binding application content
As with any other standard (e.g. SQL) you pick these functions that are useful in your scenario, and you drop the other functions that are not useful – and that's exactly how we approached JSF.
Most of the existing JSF libraries and frameworks use JSF as framework to create (full) HTML pages.
JSF manages a server-side tree of component-instances. This tree is processed by browser requests – and the HTML-response is rendered by recursively rendering each component into its HTML representation. The result is a full HTML document which then is passed to the browser, which then renders the HTML correspondingly.
JSF as consequence allows the server-side application to work with a component model – and not to work with the HTML-technology natively. But: of course the approach to always render full HTML pages is not really user-friendly – the browser content is flickering with every request, scroll and keyboard focus get lost. To overcome JSF also included AJAX concepts, in order to only partially refresh HTML pages – but these concepts are not trivial to use for application processing.
Now let's take a look into the CaptainCasa way of using JSF:
The rendering-client of CaptainCasa is a JavaScript program that is loaded into the browser when calling a URL with extension “.risc”. This JavaScript program is now the one that talks to the server in order to get to know what to render. For talking to the server, the XmlHttpRequest-API is used.
This means: requests from the client-processing to the server are NOT originated by some URL that is resolved in the browser, but requests are originated by the rendering-client's JavaScript logic.
The rendering client expects the server to send some layout definition. This definition is sent in an XML format that is defined by CaptainCasa (and which extensible in order to add own components).
You now already see: the server-side processing in principal is very similar to the traditional approach: it manages a tree of component-instances which now does NOT recursively render into HTML, but which renders into the XML format that is required by the client.
The XML definition that is defined by CaptainCasa is optimized for performance. After having sent a full layout to the client side with the first round trip, only changes of the layout are transferred afterwards. These changes both include updates of data-content in existing components (e.g. a label's value is update) and structural changed of the whole layout (e.g. new areas are rendered, other areas are removed).
The consequence of this management of changes is:
The data volume of reach round trip is drastically reduced.
The performance on client side is drastically improved, because the client exactly knows where changes in user interface have to be rendered.
This is the reason why round-trips between the client and the server are lightweight round-trips – where as round-trips with traditional JSF frameworks are heavyweight (full page's HTML is exchanged).
CaptainCasa uses JSF as standard for Server-side interaction processing.
But: CaptainCasa has nothing to do with traditional HTML-based rendering, which you might “by default” associate with JSF. JSF is a good standard which can server any UI-client – such as the HTML browser itself and/or the CaptainCasa “JavaScript-rendering-client” that runs inside the browser.
The server-side of CaptainCasa is stable from 2007 on (using JSF as described above). Same with the XML-protocol between client- and server-processing.
What did change in the history was the client technology. CaptainCasa started in 2007 with a Java-Swing-based client, 2012 added a JavaFX-based version and in 2017 came up with the RISC-HTML based JavaScript client that you now use.
In 2020 CaptainCasa introduced on own “mini-JSF-implementation” that can be used as alternative to the JSF reference implementation, that was used as default before. We always point out that this mini-JSF-implementation must only be used together with CaptainCasa – it is NOT a general multi-purpose JSF engine – because it is functionally restricted to these functions that are used by CaptainCasa.
The reasons for implementing a mini-JSF-implementation were:
Have the full server-side layer on top of the servlet engine under full control by CaptainCasa.
Performance optimizations.
Independence of the CaptainCasa framework from other frameworks within its core parts.