Skip to main content

Overview

Tripetto is an integral and unique solution for creating and running forms and surveys. The following diagram shows an overview of the fundamentals of Tripetto. It shows the core components, and the JSON data types used to exchange data between them.

Overview diagram

📦 Components​


A Builder

Builder component of Tripetto that is used to create forms (form designer). It is a visual UI component that allows building smart flowing forms and surveys like flowcharts in the browser. End users who edit forms are working in the builder.
📖 Documentation 🚀 Quickstart


B Blocks | Builder part

Blocks are the question types in Tripetto (each question type is a block). They exist out of 2 parts and this is the builder part that is used to manage the properties/settings for a block in the builder.
📖 Documentation 🎓 Tutorial


C Runner | Runner UI

Runners are used to render the form definition to a working UI and collect the response data. Form respondents filling out a form are working in a runner. The runner UI is only responsible for rendering the form and handle user interaction. Everything else is handled by the Runner library which is the workhorse of the runner.
📖 Documentation 🚀 Quickstart


D Blocks | Runner part

Blocks are the question types in Tripetto (each question type is a block). They exist out of 2 parts and this is the runner part that is used to render the block to a visual UI in a runner.
📖 Documentation 🎓 Tutorial


E Runner Library | Runner workhorse

Each runner consists out of 2 layers, the runner core layer and the runner UI layer. The Runner library is the workhorse of a Tripetto runner. It turns a JSON form definition (the output of the builder) into an executable program; a virtual finite state machine that handles all the complex logic and response collection during the execution of the form.
📖 Documentation

📡 Data types​

info

All the data types are valid JSON and can be converted to a string using JSON.stringify or constructed from a string using JSON.parse. For each object TypeScript annotation is available. Some also have a JSON Schema.


1 Form definition | Builder output

Forms in Tripetto are defined by their form definition. It is a single JSON object that holds the complete structure of a form. It follows the IDefinition interface. The object is generated by the form builder (output) and consumed by a form runner (input).
📖 Documentation 📄 JSON Schema


2 Form styles | Builder output

Form styles are JSON objects that hold style settings (colors, font, etc.) for a form runner. It depends on the form runner if it supports styles, but if it does, the builder can be used to show an editor panel where the user can configure the available style properties.
📖 Documentation


3 Form localization (l10n) | Builder output

Form l10n JSON objects specify (custom) translations/locale information to the runner. They give the user more control over the l10n-related settings (for example, set a fixed translation and locale for a form) and even allow them to create their own translations for a runner.
📖 Documentation


4 Translations | Static assets

Translations for the builder and runners are static assets. They are included in the builder and runner packages and can either be imported during design time or served (through an endpoint) during run-time.
📖 Documentation


5 Locales | Static assets

Locales are used for localizing (formatting) things like dates, numbers, etc. Locales are also static assets that are included in the builder and runner packages. They can either be imported during design time or served (through an endpoint) during run-time.
📖 Documentation


6 Response data | Runner output

The response data is the output of a runner. It's the actual form data that is submitted by a form respondent. Tripetto supports various formats for exporting the data.
📖 Documentation 📄 JSON Schema


7 Pause (snapshot) data | Runner output

Pause (or snapshot) data is generated when a runner is paused. Pausing a form allows a respondent to temporarily stop filling in a form and then continue at a later moment. Not only the submitted data is stored, but also the actual state of the runner. That allows the runner to return to the exact state the respondent left it in.
📖 Documentation 📄 JSON Schema