Разработка собственных компонентов

Алгоритм разработки компонентов требует строгого следования порядку очередности блоков кода, поскольку блоки жёстко взаимосвязаны и не могут быть расположены в произвольном порядке, что привело бы в худшем случае к ошибке выполнения, в лучшем - к падению производительности при построении и отображении модуля.

В классах визуальных компонентов sFF не должно быть ничего, кроме конструктора. Это требование для соблюдения трёхуровневой адресации свойств и методов. Если нарушить это требование, например, разрешить компоненту Panel иметь прямое (без включенного класса Signal) свойство focus (являющееся событием), то при наследовании от панели других классов никогда больше будет нельзя будет использовать название focus ни для каких иных методов, ни для свойств, чтобы не переназначить его. Таким образом разработчик классов будет должен либо изменить смысл свойства focus в дочерних классах (тогда будет утеряно единообразие именования и нужно будет помнить смысл свойства-события-метода для каждого класса), либо дописывать ему уточняющие названия (что приведёт к невероятно длинным и незапоминающимся конструкциям).

При этом трёхуровневая адресация с лёгкостью объединяет во включённые классы и объекты-контейнеры свойств и методов, и настоящие агрегаты (внутренние классы, создаваемые при помощи директивы new).

Создание свойств по умолчанию необходимо для корректной работы конструктора компонента. При прописывании типа свойства необходимо гарантировать его корректную обработка в процессе создания компонента. В противном случае интерпретатор будет воспринимать неизвестные свойства в качестве строковых-редактируемых-видимых, что может привести к ошибкам в процессе выполнения конструктора. Можно, конечно, не указывать типы свойств по умолчанию и преобразовывать их из строковых к необходимым типам при записи значений, но это приведёт к отсутствию значений по умолчанию в карте $_GC().Class и созданию лишних атрибутов свойств в результирующем SFM-файле модуля, что, в свою очередь, вызовет выполнение лишних операций в каждом из экземпляров класса компонента и, соответственно, падение производительности при отображении модуля.

При разработке классов необходимо создавать свойства посредством их объявления методом Object.defineProperty. В случае использования аксессоров (сеттеров-геттеров) при построении компонента из карты (Map) входных параметров в процессе проверки наличия свойств в объекте перед присвоением значения, в консоль будет выведено warn-сообщение об отсутствии указанного свойства в составе включенного класса компонента, но ошибка не вызывается. В случае прямого присвоения свойства вызовом команды (в процессе редактирования отображенного модуля либо выполнения пользовательской функции) подобная проверка не производится и сообщение не выдаётся. Но при последующей загрузке карты входных параметров, в консоль будет выведено данное предупреждение.

При наличии внутри класса компонента дополнительных элементов, кроме элемента позиционирования pane, необходимо при их создании в конструкторе указать идентификатор родительского компонента, присвоив его значение data-атрибуту compId дочернему элементу. Кроме того, что данный data-атрибут дочернего элемента класса будет не только указывать на факт наличия родительского компонента у дочернего элемента, но и ускорять его поиск в карте компонентов приложения (ACM). Операция создания data-атрибута compId должна находится после вызова функции применения входных параметров компонента $_GC().acceptInputParams, когда id компонента (id элемента позиционирования) уже будет сформирован.

Установка свойств по умолчанию для включенных классов в компонентах производится в конструкторе класса компонента после создания самого включенного класса.

Для каждого из компонентов в его конструкторе могут быть установлены собственные цвета состояний по умолчанию, которые могут быть изменены главной таблицей стилей приложения либо объявлением стиля класса (при включенном Panel.useCSS), либо объявлением стиля элемента (при выключенном Panel.useCSS). Назначение цветов состояний по умолчанию должно осуществляться в блоке объявлений значений иных свойств по умолчанию перед вызовом функции применения входных параметров компонента $_GC().acceptInputParams.