Basics

ADITO is based on the Unified Entity Model, meaning all business objects are structured in so-called Entities. ("Entity" and other technical terms like "Context", "View", etc. are written in upper case, in order to distinguish them from their meaning in everyday language.) The features of business objects are represented by "EntityFields". For example, the business object "Person" is modeled as an Entity named "Person_entity", with EntityFields such as "FIRSTNAME", "LASTNAME", and "DATEOFBIRTH".

The data held by an Entity is stored via a so-called RecordContainer, which mainly acts as an interface to the actual storage location, typically a database. The RecordContainer includes a mapping of EntityFields to their corresponding database columns and manages database access by generating all required SQL statements, including "select", "insert", "update", or "delete".

An Entity and its RecordContainer comprise the core business logic, e.g., through a "conditionProcess" that allows adding a "where" condition to an SQL select statement.

The visualization of data in the web client is organized via so-called ViewTemplates, which reference the EntityFields whose values are to be displayed. ViewTemplates are available in various design types, such as table, tree, list, or bar chart. ADITO's UX management ensures that all ViewTemplates follow a uniform design, meeting quality criteria such as readability, consistency, and intuitive usability.

Every ViewTemplate is embedded in a so-called View, which acts as a container for multiple ViewTemplates, other Views (allowing nesting), and references to Views of other Contexts. In principle, the data of one Entity can be visualized by an arbitrary number of Views.

A so-called Context forms a logical cluster around one Entity and its Views. A View can also be re-used, by referencing them in other Contexts.

To sum up, the ADITO concept is based on a clear separation between

• data structure and logic ("Entities"),
• data storage ("RecordContainer"), and
• data presentation ("Views", organized in "Contexts").

To use a View in another Context, a connection between the 2 corresponding Entities must be established, by designating one Entity as a "Provider" and the other Entity as a "Consumer".

The Context

A Context is an ADITO model that clusters one Entity with an arbitrary number of Views, via the Context's properties entity and xxxView. You can create a new Context via option "New" in the context menu of the folder "context" in the project tree (window "Projects").

The Entity and its content

Entities are the central structural and logical elements in ADITO. All business objects and their logic are represented in Entities. An Entity has various configurable properties, including static values (e.g., a title or various flags) and code-based properties (e.g., initFilterProcess for initial filtering). You can create a new Entity via option "New" in the context menu of

• the folder "entity" in the project tree (window "Projects"). In this case, the Entity needs to be assigned to a Context in a separate step.
• an existing Context. In this case, the Entity will be created and automatically be assigned to the Context (the Context's property entity will be set with the name of the Entity). Thus, in practice, this way is more common.

An Entity's consists of several components: EntityFields, RecordContainers, Actions, Providers, Consumers, and Parameters.

Let's take a closer look at these components.

EntityFields

EntityFields represent the attributes of an Entity. For example, "Person_entity" includes EntityFields like "FIRSTNAME", "LASTNAME", and "DATEOFBIRTH". Each EntityField has configurable properties, some static and others are defined via processes, such as the mandatory flag and a corresponding mandatoryProcess.

Commonly used properties are:

• title: A text that identifies the EntityField in the client, e.g., it will be displayed as column title in a tableViewTemplate or as lable of a list item in a genericViewTemplate.
• contentType: The ADITO data type (default: TEXT). It must correpondend to the data type of the connected database. When you set contentType DATE, you also need to consider property resolution.
• mandatory: This property is part of an automatic input validation. If checked, the setting of this EntityField is prerequisite for creating the dataset. If it is not set, the save button will stay disabled, and the message "Required value is missing" will be shown.
• linkedContext: Here, the related Context should be set for all EntityFields acting like "foreign keys". The effect of this property is that, in the client, the respective EntityField values will be displayed with a hyperlink, allowing you to open the corresponding dataset in the MainView of the related Context.

Views

A View is an ADITO model that clusters so-called ViewTemplates of various types, e.g., a table or a list. The ViewTemplates, in turn, reference one or multiple fields of the Context's Entity.

Usually, the only property you need to set in a View is its layout, which defines the appearance and the order in which the ViewTemplates and their EntityFields are displayed.

ViewTemplates

ViewTemplates are the ADITO models that define the data that is to be shown, and how this data is actually displayed - as a table or a list or a diagram etc. There are multiple types of ViewTemplates: Here you can find a detailled description of every available type.

To create a new ViewTemplate for a specific View, open the View in the "Navigator" window (by double-clicking on it in the "Projects" window), right-click on it and choose "Add ViewTemplate..." from the context menu. Subsequently, you need to select the ViewTemplate type and give the new ViewTemplate a name.

Here is an overview of what ViewTemplate types to use for the standard Views:

Standard View	layout	ViewTemplate type
FilterView	GroupLayout	Table, TreeTable
EditView	BoxLayout	Generic (editMode: true)
PreviewView	HeaderFooterLayout	Header: Card; Footer: ScoreCard; in between: Generic
MainView	MasterDetailLayout	-- (reference PreviewView as master)

The EntityFields to be shown need to be entered in the Field-related properties of the ViewTemplate, e.g., columns (tableViewTemplate) or fields (genericViewTemplate).

RecordContainers

RecordContainers define the source of the user data, be it a database or some logic, or a combination of both. There a multiple types of RecordContainers:

• A Database RecordContainer (dbRecordContainer) specifies the database and the respective table(s) and columns to be used for handling the data. This type of RecordContainer enables an easy-to-establish connection of EntityFields and database columns. In the background, it automatically generates all required SQL statements for loading (select), changing (update), creating (insert), ordering (order by), and deleting (delete) data.

• A JDito RecordContainer (jDitoRecordContainer) is lesser automated than a Database RecordContainer, but it is more flexible. A central property named contentProcess allows the use of JDito code to specify the values of the EntityFields, whether they are calculated or included from a database.

• An Index RecordContainer (indexRecordContainer) reads/writes data from/to an "index". In ADITO, the "index" is a kind of parallel data container that can be filled with selected data from connected ADITO databases (e.g., name and address of contact persons or companies). Through this data reduction, a special data structure, and a special database (comparable with a NoSQL database), the data included in the index can be scanned and read very quickly using the Apache Solr search engine. An IndexRecordContainer can be used in various ways, with the "Global Search" being the most common. Additionaly, an Index RecordContainer can also be used as an alternative data source for EntityFields if the usage of a Database RecordContainer or JDito RecordContainer is not suitable or does not meet performance requirements.

• A Dataless RecordContainer (datalessRecordContainer) is used in special cases, when no data container is required. This enables pure data input, which can then be processed, e.g., via an Action.

tip

In chapter RecordContainer you can find more detailed explanations on the topic.

Actions

An Action in ADITO is an option to execute arbitrary JDito code. Besides the predefined Actions (save, new, cancel, delete, etc.), you can specify additional Actions according to your requirements. In the web client, Actions are visible either as buttons or as list items of a combo box. An Action's main property is the onActionProcess. Here, you enter the actual code that is to be executed when the user selects the Action.

Providers and Consumers

Providers and Consumers are configuration models that enable dependencies between Entities, in order to exchange data. A Provider is created for the Entity that sends data to another Entity. This means, a Provider provides data that is requested by another Entity.

A Consumer is the counterpart of a Provider: A Consumer is created for the Entity that requests data. Via the Consumer's properties entityName and fieldName you configure to which Entity and to which Provider the Consumer should be connected.

Thus, the 2 Entities are connected. An Entity can have multiple Consumers and multiple Providers. A Consumer can only be connected to one single Provider. But a Provider can be connected to multiple Consumers.

Colloquially, ADITO developers sometimes speak of the providing Entity itself as "the Provider".

To sum up: The Provider provides data, and the Consumer uses these data. These mechanisms allow Entities to communicate with each other.

Parameters

Parameters enable the Entity to react specificly after it has been called, depending on the Parameter's value. Parameters are mostly used in combination with a Provider/Consumer relationship. Find more information in the sub-chapter Parameter.

Programming Languages

Although, in general, ADITO follows a low-code approach, there are various case that require programming. Commonly, the following languages are required:

• JDito, for processes (see project folder "process") and process properties, e.g., an Entity's property mandatoryProcess. Here you can find more information about JDito.
• XML, e.g.,
  • for controlling database operations using Liquibase
  • to be used in JDito, see chapter XML in JDito
  • for understanding the source code of ADITO models, which is stored in files with the extension .aod (see tab "Source" in the Editor area of the ADITO Designer)
• JSON, to be used in JDito in special cases
• SQL, for database operations, e.g., using the SqlBuilder
• AsciiDoc, for writing documentation, using the properties documentation. See here.