What is the Nocode Model?

It is the unit in which data sources (database) or formulated values are defined in the NoCode environment. With the model, definitions are made for reading and writing the required values for a form or graphical interface from the database.

The model is built on one or more structures. Structures are the model grouped by data groups. If it is necessary to explain this with an example, with a current account record, it enables the transactions of this current account to be grouped with two different Structures in the same model.

Struct - Structures

Structures are made up of two types; main and sub. A Structure defined as Main represents the top-level set of a single data set or a hierarchical data set. A sub-defined Structure corresponds to the main dataset items corresponding to an item belonging to this main registered. This hierarchical structure contains configuration settings in the model to specify the relationship of the sub-defined Structure to the main-defined Structure. Thus, related data in subsets of a main set of data are defined in a single model. Relational relations between models are not made at this level, all relations to be made at this level include datasets (i.e. items such as tables or images).

Structures are based on elements. Elements can be thought of as a form element, with configuration settings such as a displayer, label by language, data type, display on the screen (such as text field, option list), table and column correspondence, and relationships with workcube objects. In this way, when elements are dragged and dropped on a block (widget), it tells the block how it will look and with what rules it will work. It is determined which events will be used according to the Elements configuration settings.

Elements

Element is the most basic unit and is the primary source for data matching. According to the table or tables in which the elements in a structure, queries belonging to the structure are automatically created. For this reason, it is important to determine which data source each element uses. As well as matching the elements correctly, the data type of the element must be chosen correctly. It is necessary for the correct display and/or saving of the data received from the source, to be delivered in the correct format.

Whether the elements will be used according to the events is also determined on the model. While an element cannot be used in a record insert event, it can be used in a record update event. The distinction at this element level is governed by the model. Thus, an item that will not be used in an event cannot be a part of that event while block designs are being made. Events are defined as adding, updating, listing and dashboard. However, listing carries two types of data, list fields and filter fields. In this context, elements of 5 types are associated with events.

Condition Concept

While the Structure ensures that the elements work together, it also tries to establish the relationship of these elements with the data. However, if more than one dataset (on more than one table) runs in a structure, it also needs to define its relational structure. It will ask us to specify the structure conditions for this situation. The data of the data sets are matched by determining the left-right matching under Conditions and the connection between the data and the synchronization method (equal, greater, lesser, etc.). In the conditions area, where relationships are made between data sources, it also sets constraints on the data by taking the data from a constant or system data (such as a session). After associating the structure elements and the datasets to which the elements are connected, it can generate the query generation itself. After a model is designed, it is possible to look at its front view and check the correctness of the generated queries (requires expertise). If a query is not generated correctly, the likely case is that the elements and conditions are not configured correctly.

Consistency

The visual and form settings on the elements are depicted at the model level but are not used in the code generation phase of the model. For this reason, this information about blocks (widgets) will be mentioned. It is useful to follow this checklist for an accurate model:

• Are the data sources of the elements connected correctly, and are the data types selected with their appropriate counterparts?
• Are element names uniquely defined in the structure?
• Have the desired events for the elements been selected?
• Are the conditions matched for elements with different data sources?
• Are sub-structures and main-structures relations connected?

Models developed by considering the information in this list will produce dynamic code without any problems.