Skip to end of metadata
Go to start of metadata

The form structure is a complex of objects, properties, actions and relations between them.


When creating a form, first you must define which objects it will display. For each form object you need to specify its class.

It is possible to combine objects into object groups. In this case, the table will show a "Cartesian product" of these objects (i.e., for two objects - all pairs, three objects - triples, etc.). 

In accordance with the order of adding object groups to the form, an ordered list of object groups is formed. Accordingly, the group with the maximum number for a certain set of object groups shall be called the last group for this set (i.e., the latest). The last group for a set of objects is determined similarly: first, a set of object groups into which these objects are included is built, then the last group is determined for the obtained set of object groups.

Each object on the form has a current value at any time. It changes either as a result of corresponding user actions in interactive view or "virtually" while reading data in static view.

Properties and actions

After defining objects, you can add properties and actions to the form, passing these objects to them as arguments.

Adding actions is relevant only for interactive view. In static view added actions are ignored.

The behavior of properties and actions in the context of their display on the form is absolutely identical, therefore, in the rest of this section, we will use only the term property (the behavior for actions is completely similar).

Display group

Each property is displayed exactly in one of the object groups on the form (this group shall be called a display group of this property). By default, the display group is the last group for the set of objects which this property receives as an input. If necessary, the developer can specify the display group explicitly (with certain constraints when used in a structured view)


By default, a property is displayed in its display group exactly once. In this case, the values of objects which are not in the display group of this property (these objects shall be called upper) are used as their current values. However, it is also possible to display one property multiple times so that all object collections are used as the values of certain upper objects (not their current values). With this display of the property, a kind of "matrix" is formed - upper objects x objects of the display group. Thus, to create such a matrix, when adding a property to the form you must specify which upper objects (specifically, object groups) must be used to create columns (these object groups shall be called groups-in-columns).

When determining a display group, properties of the group-to-columns are ignored.

Property groups

Properties on the form can be combined into groups which, in turn, are used in the interactive (default design) and hierarchical form views. By default, a property is included in a group globally (i.e., this inclusion is defined for a property for all forms at once), however, this inclusion can be redefined for particular forms.

Default settings

Properties on the form have a large number of display settings in various views, most of which can be set not only directly for the property on the form, but also for the property itself (when creating it). These settings will be the default settings, i.e., if the setting is not explicitly set for a specific property on the form, then the setting of the property itself is used. In addition, these default settings are "inherited" when using composition, selection and previous value operators (i.e., if property f(a) has the default width of 10, then the property g(a) = f(a) IF h(a) will also have a width of 10 by default).


For each form, the developer can create filters which will limit the list of object collections available for viewing/selection on the form.

To define a filter, you must specify a property that will be used as a filter condition. The filter will be applied to the table of the object group that is the last for the set of objects which this property takes as input (i.e., similar to the definition of the property display group). In this case, only those object collections (rows) for which property values are not NULL will be shown.


By default, in all object group views, object collections are displayed in a certain non-deterministic order, which is determined by the specific implementation of the platform (most often, internal identifiers are used to determine the order). If necessary, the developer can define this order explicitly by specifying a list of properties on the form that will be used as orders. At the same time, for each property in this list, you can specify whether the order should be ascending or descending (by default, the ascending option is used).

NULL value is always considered to be the smallest value. 


To create a new form and define its structure, the FORM instruction is used.



 CLASS Document;

// declaring the Documents form
FORM documents 'Documents'
    OBJECTS d = Document // Adding one object of the Document class. The object will be available by this name in the DESIGN, SHOW, EXPORT, DIALOG, etc. operators.

    // ... adding properties and filters to the form 

    LIST Document OBJECT d // marking that this form should be used when it is necessary to select a document, while the d object should be used as a return value

// declaring the Product form
FORM item 'Product'
    OBJECTS i = Item PANEL // adding an object of the Item class and marking that it should be displayed in the panel (i.e., only one value is visible)

    // ... adding properties and filters to the form 

    EDIT Item OBJECT i // marking that this form should be used when it is necessary to add or edit a product

// declaring a form with a list of Products
FORM items 'Products'
    OBJECTS i = Item

    // ... adding properties and filters to the form 

    PROPERTIES(i) NEWSESSION NEW, EDIT // adding buttons that will create and edit the product using the item form

CLASS Invoice;
CLASS InvoiceDetail;

// declaring the invoice print form
FORM printInvoice
    OBJECTS i = Invoice // adding an object of the invoice class for which printing will be executed

    // ... adding properties and filters to the form 
// splitting the form definition into two instructions (the second instruction can be transferred to another module)
EXTEND FORM printInvoice
    OBJECTS d = InvoiceDetail // adding invoice lines, each of which will be used in the report as a detail

    // ... adding properties and filters to the form 
print (Invoice invoice)  { PRINT printInvoice OBJECTS i = invoice; } // declaring an action that will open the invoice print form

  • No labels


  1. Ты же понимаешь что в редактировании селектор и только для чтения это частные случаи первого пункта у которых действие пустое и выбора объекта по умолчанию. Кстати что она будет делать если я написал ON CHANGE EXEC и READONLY?

    То есть вообще гря редактирование - это просто клиентское событие, которое как и обычное событие вызывает действие, которое в свою очередь может быть обработкой по умолчанию, обработкой READONLY, SELECTOR или actionMapping,

    И вообще по сути должен быть подраздел События формы (клиентские события) - у которого варианты - Редактирование, Групповое редактирование, Редактирование WYS (Paste), Нажатие клавиши, и соответственно когда возникают, что вызывают / могут вызывать

  2. Ну начнем с того, что у нас сейчас в логике не так. То есть пустой ACTION на редактирование свойства, и выставленный маркер READONLY будут вести себя по разному.

    1. Это почему? С пустым ACTION'ом ничего не произойдет. И с readonly. Вопрос только с автостартом фильтра но он вроде тоже через клиентские события сделан. Так я не понял а что сейчас будет если readonly и on change прописать ?

  3. И вообще если подумать то события + действия (так как на форме они только так и вызываются через обработчики событий) - Controller, структура формы + сессии + свойства - model, а дизайн формы + алгоритм обновление (endApply на сервере, processFormChanges на клиенте) - View. Тут возможны варианты : структура формы - во view, или даже что более четко дизайн формы в model (собсно все равно, так как в классических языках нет разделения на свойства и структуры формы, куда там идет дизайн хрен поймешь). Хотя конечно главный идиотизм, в том что View - в большей степени алгоритм (физическая модель), а Model и Controller - логическая модель по этому сильно ориентироваться на паттерн MVC не стоит. Но разделить описание в этом направлении по моему стоит.