Rendering

Questionnaires are rendered into bytestreams for presentation.

Rendering is performed by stateless engines in accordance with client directives, including the bytestream that serves as a sink for the project and the target publication format. The outcome of rendering includes a list the errors encountered in the process, if any.

Different engines target different publication formats. Engines are automatically discovered and indexed by a engine registry, where they can be looked up by format.

The lookup is performed by a service, which executes the process in a transactional context, either synchronously or asynchronously, notifying any interested party of outcomes.

A Web API triggers the process on demand, hydrating directives from JSON representations. Through the API, the outcome is finally relayed to clients, typically users, as an HTTP response with appropriate semantics.

Engines render the layout one component at the time, starting from pages and progressing depth-first along the component hierarchy.

For each component, the process is delegated to a renderer that specialises for the type of the component. Renderers are automatically discovered and indexed in a renderer registry, where they can be looked up by type.

Engines maintain a context for the rendering process, propagating it to renderers. In it, the renderers find questionnaire, directives, accumulated errors, and other services, utilities, and info that may be required to carry out the process for the target format.

The structure of the process is constant across engines, i.e. does not vary from format to format. Yet offline formats are rendered at the backend and online format at the front-end. For back-end processes, specialisation can be pushed into contexts, renderers, and pre/post-rendering actions.