Реализация новых контекстов

Многие плагины контекстов добавляют новые типы контекстов в дерево контекстов AggreGate Server. В большинстве случаев эти дополнительные контексты придерживаются типичных двухуровневых парадигм:

  • Контекст контейнера, который находится в контексте пользователя, которому он принадлежит
  • Системные администраторы, инженеры и пользователи создают экземпляры дополнительных контекстов в этом контейнере

Например, контекст контейнера Тревоги и множественные контексты Тревога, определенные пользователем, следуют этой парадигме.

Многие классы, относящиеся к контекстам сервера, скорее являются частью AggreGate Server, нежели частью Java SDK с открытым исходным кодом. Эти классы недоступны в исходном коде. Чтобы получить доступ к этим классам, нужно добавить следующие файлы JAR к пути класса:

  • aggregate-commons.jar
  • server-core.jar

Эти файлы JAR можно найти в подпапке /jar установочной папки AggreGate Server.

Добавление нового контейнера для контекстов, определенных пользователями, включает в себя набор шагов:

  • Реализация класса контекста контейнера (контекст, который содержит в себе объекты бизнес-логики)
  • Реализация класса контекста для пользовательского ресурса (например, контекст объекта бизнес-логики)
  • Регистрация Создателя контейнера ресурса
  • Создание контекстов агрегации

    • Реализация класса контекста контейнера

    Контексты контейнера (такие как контекст Тревога или Виджет) наследуются от EditableChildrenContext. Чтобы реализовать контейнер для ваших пользовательских ресурсов, необходимо унаследовать класс из EditableChildrenContext путем вызова конструктора: public EditableChildrenContext(String name, String objectName, Class<? extends EditableChildContext> childClass, TableFormat childInfoFormat)

    Ниже представлено значение параметров конструктора:

    Параметр

    Описание

    name

    Имя контекста контейнера.

    objectName

    Доступное для чтения описание дополнительного ресурса, например, "Тревога".

    childClass

    Класс контекста пользовательского ресурса. Может быть унаследован от EditableChildContext.

    childInfoFormat

    Формат переменной, которая представляет основную настройку пользовательского ресурса. Пользователи должны будут вводить эти данные на протяжении процесса создания ресурса. Эта переменная должна содержать поля строк name и description.

    Использование статических экземпляров TableFormat всегда является предпочтительным поведением.

    Такой же формат должен быть использован для переменной childInfo контекстов пользовательских ресурсов.

    Есть два метода, которые следует всегда переписывать в пользовательской реализации EditableChildrenContext:

    • Метод setupMyself(). Реализация этого метода должна настроить контекст самостоятельно, также добавить дополнительные переменные, функции, события и действия.
    • Метод buildChild(String cname, boolean readOnly, String type). Этот метод должен возвращать экземпляр контекста пользовательского контекста, который должен быть унаследован от EditableChildContext. Имя возвращенного контекста должно соответствовать входному параметру cname.

    Количество методов EditableChildrenContext обычно вытекает из реализаций setupMyself():

    • addCreateAction() для активации создания пользователем дочернего ресурса
    • allowGrouping() для поддержки группирования пользовательских ресурсов

    Реализация класса контекста пользовательского ресурса

    Контексты, соотносящиеся с вашими пользовательскими ресурсами (так, например, контекст соответствует Тревоге или Виджету), должны быть унаследованы от EditableChildContext. Их создание происходит с помощью метода buildChild()от EditableChildrenContext, описанного выше.

    Общедоступный конструктор EditableChildContext  - это public EditableChildContext(String name, boolean allowMakeCopy). Он принимает имя контекста (которое по факту относится к buildChild() как аргумент) и флажок, определяющий, будет ли действие Создать копию включено для контекста пользовательского ресурса.

    Реализации EditableChildContext должны перезаписать метод setupMyself() для персонализации самого контекста, а также для добавления дополнительных переменных, функций, событий и действий.

    Код загрузки контекста обычно ссылается на следующие методы EditableChildContext:

    • Вызов super.setupMyself() добавляет все необходимые основные переменные и действия.
    • Выполнение addChildInfoVariable(TableFormat rf, boolean readOnly) добавляет переменную childInfo к контексту пользовательского ресурса. Его формат должен соответствовать childInfoFormat, передающемуся конструктору EditableChildrenContext, и включать в себя поля name и description.
    • addConfigureAction(), addDeleteAction() и addReplicateAction() добавляют действия Конфигурировать, Удалить и Реплицировать соотвественно.

    Регистрация редактора контейнера ресурсов

    Идея ResourceContainerBuilder заключается в необходимости добавления контейнеров контексту Пользователь и удалении их в подходящие моменты. Сам редактор обычно должен наследоваться от DefaultResourceContainerBuilder и быть зарегистрированным методом ContextPlugin от install(ServerContext context).

    Далее следует код в качестве примера добавления редактора контейнера ресурсов для тревог.

    if (context instanceof UserContext)

    {

      UserContext uc = (UserContext) context;

      

      uc.registerContainerBuilder(new DefaultResourceContainerBuilder(ContextUtils.scriptsContextPath(ContextUtils.USERNAME_PATTERN))

      {

        @Override

        public void buildImpl(UserContext context) throws ContextException

        {

          context.addChild(new AlertsContext(context));

          context.addVisibleChild(ContextUtils.alertsContextPath(context.getName()));

        }

        

        @Override

        public void dismantleImpl(UserContext context) throws ContextException

        {

          context.removeVisibleChild(Contexts.CTX_ALERTS, false);

          context.removeChild(Contexts.CTX_ALERTS);

        }

      });

    }

    Метод buildImpl() добавляет контекст контейнера UserContext и регистрирует его как видимый дочерний. Метод dismantleImpl() возвращает эти операции.

    Создание контекстов агрегации

    Добавления самого контейнера в контекст пользователя недостаточно, потому что отображаемый для любого администратора AggreGate Server корень видимого дерева  демонстрирует видимые дочерние части контекста корня сервера.

    Поэтому контекст корня сервера также должен демонстрировать контексты, содержащие контекст пользовательских ресурсов в качестве дочерних. Эти контексты называются контекстами агрегации.

    Больше информации о преобразованиях этого контекста доступно в статье Видимое и действительное дерево контекстов.

    Итак, необходимо включить группирование для пользовательских ресурсов.

    Создание контекстов агрегации и контекстов групповых контейнеров представлено посредством одного статического вызова ServerContextUtils.createAggregationContexts(Context context, String containerName, String containerDescription, String iconId, String helpId, String groupContainerDescription, boolean mapGroups, String... additionalChildren).

    Ниже представлен пример того, как создаются контексты агрегации для тревог:

    ServerContextUtils.createAggregationContexts(contextManager.getRoot(), Contexts.CTX_ALERTS, "Alerts", "st_alerts", null, "Alert Groups", true);