maintenance app

обслуживание-приложение

Приложение конфигурация

Приложение для обслуживания в значительной степени обусловлено конфигурацией приложения и схемами из API. Схемы читаются непосредственно из API (по D2). Следующие документы конфигурация приложения:

• Внутри src/config/ ...
  • maintenance-models.js
  • field-config/ содержит конфигурацию для каждого типа модели
    • field-order.js определяет порядок полей в форме для каждого типа модели
    • field-groups.js определяет группировку полевых поля для формы для каждой модели. В настоящее время это используется только для программ, но это может быть хорошей идеей, чтобы расширить его на другие типы моделей.
  • field-overrides/ содержит дополнительную конфигурацию для полей, которые требуют нестандартного поведения. Чаще всего это означает поля, которые требуют специальных компонентов.
    • index.js перечисляет все модели, которые имеют одно или несколько переопределения поля
    • Фактические переопределения поля указаны в файлах, названных в честь каждого типа модели, которые, в свою очередь, импортируются в index.js . Некоторые типы моделей или поля, которые требуют большого количества логики, разделены на подпапки.
  • inlinehelp-mapping.json Определяет отображение из каждого раздела/типа модели на страницы в документации.
  • field-rules.js содержит условную логику, которую можно использовать для отображения или скрытия полей или установить значения поля на основе значения других полей.
  • periodTypes.json содержит список типов периодов, которые поддерживаются текущей версией API.
  • disabled-on-edit/ содержит файлы, в которых поля списка, которые всегда будут отображаться как только для чтения при редактировании объекта.
    • index.js Импорт Списки имен полевых имен из файлов, названных в честь каждой соответствующей модели

Для этой записи «схемы» и «типы моделей» по сути одно и то же, и эти термины используются взаимозаменяемо как в приложении для обслуживания, так и в других местах. Схемы выявляются API, но не каждый тип модели перечислен в схемах. Добавить к путанице «модели» также иногда упоминаются как «объекты».

Разделы, типы моделей и поля

Для того, чтобы тип модели отображался в приложении для обслуживания, необходимо выполнить следующие условия:

• Тип модели перечислен в разделе в src/config/maintenance-models.js
• Тип модели существует в конечной точке схем в API

Как только эти условия будут выполнены, тип модели будет отображаться в приложении для обслуживания в разделе, указанном в maintenance-models.js . При создании или редактировании моделей нового типа форма по умолчанию будет содержать только несколько предопределенных полей. Для того чтобы дополнительные поля были показаны в форме, необходимо выполнить следующие условия:

• Поле указано в типе модели в src/config/field-config/field-order.js
• Поле существует в конечной точке схем для конкретного типа модели в API.

Добавление нового типа модели

Добавление новой модели в техническое обслуживание обычно включает в себя следующие шаги:

1. Добавьте тип модели в src/config/maintenance-models.js
2. Добавьте тип модели и список полей, которые должны быть показаны в форме в src/config/field-config/field-order.js
   1. (Необязательно) Если поля должны быть разделены на отдельные группы в форме, группы могут быть указаны в src/config/field-config/field-groups.js .
3. Новый тип модели теперь должен быть указан в приложении для обслуживания. Перейдите к новому типу модели и проверьте форму как при создании нового экземпляра типа модели, так и при редактировании существующего экземпляра. Если вам повезет, на данный момент все будет работать. Скорее всего, будет одно или несколько полей, которые требуют дальнейшей настройки.
4. Создайте новый файл, названный в честь нового типа модели в src/config/field-overrides/ . Откройте src/config/field-overrides/index.js , импортируйте вновь созданный файл и добавьте его в объект overridesByType .
5. Внутри нового файла переопределения поля ( src/config/field-overrides/newType.js ) начните добавлять настройки для полей, которые требуют этого. Обычно это включает в себя создание новых компонентов и/или переопределение определенных свойств поля. Посмотрите на существующие переопределения поля для примеров.
6. Строки, которые отображаются как ** string ** в пользовательском интерфейсе, отсутствуют переводы. Они должны быть добавлены в файлы переводов, расположенные в src/i18n/ . Некоторые строки генерируются динамически и могут отображаться только в определенных ситуациях, например, при попытке удалить модель. Примечание. Рабочий процесс перевода должен в какой -то момент изменить использование i18next в пользу d2.i18n .

Дополнительные особые случаи

Некоторые модели требуют настройки за пределы того, что возможно, используя переопределение конфигурации и поля. В этих случаях может потребоваться создание нового компонента верхнего уровня и связать этот компонент с специальным маршрутом в src/router.js

Примеры этого подхода включают в себя:

• Редактор программы событий: src/EditModel/event-program/EditEventProgram.component.js
• Редактор пользовательских форм: src/EditModel/EditDataEntryForm.component.js