⟵ hearthere ⟶
  • Quick start
  • Install MIT
  • Install PRO
  • Updating
  • Optimization
  • Update v4-v6
  • Backups
  • Console utility bin/totum
  • Basics for users
  • Interface and Layout
  • Tables and their parameters
  • Prefilter
  • Fields and their parameters
  • Syntax
  • Code, actions, formatting
  • Relational relationships
  • Calculation order and calculation units
  • Auto-complete calculations and timing
  • Duplicate rows and cycles
  • Comparisons
  • Functions
  • Debugging
  • Print and CSV
  • API
  • Roles and users
  • Notifications
  • Scheduled Actions
  • System tables
  • Trees
  • Anonymous tables
  • External Forms
  • Exporting and importing tables
  • [PRO] MeiliSearch
  • [PRO] Databases
  • [PRO] Custom CSS
  • [PRO] Custom docs
  • [PRO] LDAP AD
  • [PRO] File versions
  • [PRO] List-unsubscribe
  • [PRO] Dynamic fields
  • Description
  • Enabling
  • Naming Virtual Columns
  • [PRO] Only Office
  • [PRO] Auth Tokens
  • [PRO] 2FA
  • [PRO] Superlang
  • [PRO] Daemons
  • [PRO] Profiler
  • Connecting functions
  • [SRV] Installation and Connection
  • [SRV] Export, PDF, Upload, and Preview
  • [SRV] XLSX/DOCX Generators
  • PRO Dynamic Fields

    Description

    Dynamic fields allow you to form an arbitrary number of columns in the row part when opening the table:

    This is a virtual display — within the database, there is one field containing a list or array, the values of which are transformed into the display of columns.

    The width of the virtual columns, as well as their formatting, will correspond to the parent field.

    Processed only when the table is loaded. It is not possible to dynamically redraw columns depending on the specified selector. If you need to use a dynamic selector, you can set it an action code on changes that opens the same table.

    Enabling

    To switch a field to dynamic mode, you need to enable the PRO Dynamic Field parameter for it. Available for three types of fields — String, Number, Data.

    After this, regardless of the field type, it will be displayed as a field of type Data and will be marked as a technical field visible only to the Creator role.

    The field expects a list or rowList of the same size in each row, each element of which will be transformed into the value of the corresponding virtual column.

    To make this happen, you need to specify control parameters for the field in Table Formatting.

    A special control section dn=: is used for this, which is executed only at the moment the table is opened:

    dn=: rowCreate(field: "d_field" = $inner)
        inner: rowCreate(field: "titles" = $limit; field: "order" = json`[0,1,2]`)
    
        limit: listFilter(list: $format_date; key: "key" < #h_days)
            format_date: dateFormat(date: $uniq; format: "d M")
                uniq: listUniq(list: $sel)
                    sel: selectList(table: 'sales_statistics'; field: 'date'; order: 'date' asc)
    
    

    dn=: expects a row, in the keys of which the name of the dynamic fields is specified, and in the values, there are row with one of two mandatory keys:

    • titles — a list of displayed field headers or a row of key-header correspondences.

      • If not specified, technical keys will be used in the headers.
    • order — a list of keys, the order in which the virtual columns will be displayed.

      • If not specified, the order will correspond to the order of the list in the dynamic field, and in the case of row — in random order.

    Naming Virtual Columns

    To get information about the key of a virtual column in the formatting code, you need to use the variable $#nfd

    The Name of virtual columns is formed as base_field/key and can be managed from the table formatting:

    f1=: setTableFormat(condition: #h_show = false; fieldhide: "d_field/1" = "force"; fieldhide: "d_field/0" = "force"; fieldhide: "d_field/2" = "force")
    
    f2=: setTableFormat(condition: #h_show = true; fieldhide: "d_field/1" = false; fieldhide: "d_field/0" = false; fieldhide: "d_field/2" = false)
    
    

    But access to them from the code by these paths to get the value is impossible, as these fields do not exist in the database! To get the value, you need to refer to the parent field.