Перейти к основному содержимому
Версия: 7.0

Правила: дизайн форм

Правила дизайна форм​

  1. Эти правила дизайна НЕ покрывают модель раскладки DESIGN — дерево контейнеров по умолчанию, модель flexbox fill / выравнивания или идиомы контейнеров. Они дают лишь мета-советы по размещению. Перед написанием или изменением любого DESIGN ассистент ОБЯЗАН получить документацию Form_design; он НЕ ДОЛЖЕН полагаться на эти правила так, будто они описывают модель раскладки.

    Полные таблицы свойств компонентов всех видов (контейнеров, компонентов свойств и действий на форме, тулбаров, таблиц) содержатся в документации инструкции DESIGN (DESIGN_statement). Задавая компоненту свойство, ассистент ОБЯЗАН сверить его имя и допустимые значения с этими таблицами, а НЕ ДОЛЖЕН угадывать их по аналогии.

  2. Ассистенту СЛЕДУЕТ задавать DESIGN для всех интерактивных форм, содержащих более четырёх свойств.

  3. Исключение: для тривиальной формы с одним-двумя объектами в режиме GRID и без других свойств, показанных в режиме PANEL, опускание DESIGN допустимо.

  4. В DESIGN ассистенту СЛЕДУЕТ предпочитать перемещение контейнеров BOX(...) для таблиц в первую очередь.

    GRID(...) СЛЕДУЕТ использовать только при крайней необходимости.

  5. По возможности ассистенту СЛЕДУЕТ избегать дизайнов форм с более чем двумя таблицами по вертикали и более чем двумя таблицами по горизонтали.

  6. Кастомные действия, добавляемые на грид-форму (смена статуса, генерация документов, массовые операции), ДОЛЖНЫ получать явный вид TOOLBAR, например PROPERTIES(o) confirmDoc TOOLBAR. Действия по умолчанию имеют вид PANEL, поэтому без TOOLBAR кастомная кнопка рисуется отдельной группой под таблицей, а не в тулбаре грида рядом с предопределёнными NEW / EDIT / DELETE, которым платформа задает тот же вид TOOLBAR, — то есть они делят с ней контейнер TOOLBAR, а не TOOLBARSYSTEM, на чем и промахивается MOVE или REMOVE не того контейнера. Виды свойств / действий: GRID, TOOLBAR, PANEL, POPUP.

  7. Свойство типа TEXT, показанное колонкой грида, отрисовывается многострочной строкой высотой по умолчанию в четыре строки, снижая плотность списка. Такие колонки часто возникают из стандартных строковых свойств (lpad[TEXT, INTEGER, TEXT], substr[TEXT, INTEGER, INTEGER], trim[TEXT] и остальных): они, как правило, возвращают TEXT независимо от классов аргументов, и конкатенация операнда класса TEXT с ограниченной строкой — тоже TEXT. На списочных формах ассистенту СЛЕДУЕТ вместо него выставлять значение, приведённое к STRING[n]. Запись с приведением подчиняется правилам записей-выражений: в блоке PROPERTIES без заголовка с общими параметрами и с явным алиасом (shortNote = STRING[100](note(o))). Голое приведение без алиаса, как и любое выражение внутри блока с заголовком общих параметров PROPERTIES(o), — ошибка разбора; там объявите именованное свойство с приведением и добавьте его по идентификатору.

  8. Для отображения данных ассистент ДОЛЖЕН сначала рассматривать стандартные виды представления группы объектов: таблицу, сводную таблицу с её диаграммами (PIVOT), календарь (CALENDAR), карту (MAP). Пользовательское представление на компоненте React — контейнер в DESIGN с атрибутом custom; только веб-клиент, десктоп-клиент отрисовывает обычное поддерево контейнера — применяется, когда требуется что-то сверх простой таблицы, простого календаря, простой диаграммы или сводной таблицы: канбан-доска, расписание, лента карточек, схема рассадки, перетаскивание, которого нет в стандартных видах, нестандартная раскладка или интерактивность. Перед созданием такого представления ассистент ОБЯЗАН получить документацию How-to_Custom_React_views.

  9. FALSE допустим в логических атрибутах блока DESIGN — defaultComponent, activated и подобных, — потому что их значения являются литералами, а не выражениями. Правило ядра, запрещающее FALSE, касается только выражений, и его НЕ ДОЛЖНО применять здесь, переписывая на NULL.