maintenance app

App a mantener el mantenimiento

Configuración de la aplicación

La aplicación de mantenimiento está impulsada en gran medida por la configuración de la aplicación y los esquemas de la API. Los esquemas se leen directamente de la API (por D2). El siguiente documenta la configuración de la aplicación:

• Dentro de src/config/ ...
  • maintenance-models.js Define los tipos de modelos que se muestran en la aplicación
  • field-config/ contiene configuración para cada tipo de modelo
    • field-order.js Define el orden de los campos dentro del formulario para cada tipo de modelo
    • field-groups.js Define la agrupación de campo para el formulario para cada modelo. Actualmente, esto solo se usa para ProgramRules, pero podría ser una buena idea expandirlo a otros tipos de modelos también.
  • field-overrides/ contiene configuración adicional para campos que requieren un comportamiento no estándar. Más comúnmente esto significa campos que requieren componentes especiales.
    • index.js enumera todos los modelos que tienen una o más anulaciones de campo
    • Las anulaciones de campo reales se especifican en archivos que se llaman a cada tipo de modelo, que a su vez se importan a index.js . Algunos tipos o campos de modelos que requieren mucha lógica se separan en subpoletas.
  • inlinehelp-mapping.json especifica la asignación de cada sección/modelo de modelo a páginas en la documentación.
  • field-rules.js contiene una lógica condicional que puede usarse para mostrar u ocultar campos o establecer valores de campo en función del valor de otros campos.
  • periodTypes.json contiene la lista de tipos de período compatibles con la versión actual de la API.
  • disabled-on-edit/ contiene archivos que enumeran campos que siempre se mostrarán como de solo lectura cuando se edite un objeto.
    • index.js Importa listas de nombres de campo de archivos que llevan a cabo cada modelo relevante

Para el registro, los "esquemas" y los "tipos de modelos" son esencialmente lo mismo y estos términos se usan indistintamente tanto en la aplicación de mantenimiento como en otros lugares. Los esquemas están expuestos por la API, pero no todos los tipos de modelo se enumeran en los esquemas. Para agregar a los "modelos" de confusión también se conocen algunas veces como "objetos".

Secciones, tipos de modelos y campos

Para que se muestre un tipo de modelo en la aplicación de mantenimiento, se deben cumplir las siguientes condiciones:

• El tipo de modelo se enumera en una sección en src/config/maintenance-models.js
• El tipo de modelo existe en el punto final de esquemas en la API

Una vez que se cumplan estas condiciones, el tipo de modelo aparecerá en la aplicación de mantenimiento en la sección especificada en maintenance-models.js . Al crear o editar modelos del nuevo tipo, el formulario solo contendrá un puñado de campos predefinidos. Para que se muestren campos adicionales en el formulario, se deben cumplir las siguientes condiciones:

• El campo se enumera en el tipo de modelo en src/config/field-config/field-order.js
• El campo existe en el punto final de esquemas para el tipo de modelo específico en la API.

Agregar un nuevo tipo de modelo

Agregar un nuevo modelo al mantenimiento generalmente implica los siguientes pasos:

1. Agregue el tipo de modelo a src/config/maintenance-models.js
2. Agregue el tipo de modelo y la lista de campos que deben mostrarse en el formulario a src/config/field-config/field-order.js
   1. (Opcional) Si los campos deben separarse en grupos separados en el formulario, los grupos se pueden especificar en src/config/field-config/field-groups.js .
3. El nuevo tipo de modelo ahora debe aparecer en la aplicación de mantenimiento. Navegue al nuevo tipo de modelo y verifique el formulario tanto al crear una nueva instancia del tipo de modelo como al editar una instancia existente. Si tienes suerte, todo funcionará en este momento. Lo más probable es que haya uno o más campos que requieran una mayor personalización.
4. Cree un nuevo archivo que lleva el nombre del nuevo tipo de modelo en src/config/field-overrides/ . Abra src/config/field-overrides/index.js , importe el archivo recién creado y agréguelo al objeto overridesByType .
5. Dentro del nuevo archivo de anulación de campo ( src/config/field-overrides/newType.js ), comience a agregar personalizaciones para los campos que lo requieren. Esto generalmente implica crear nuevos componentes y/o anular ciertas propiedades de campo. Mire las anulaciones de campo existentes para ver ejemplos.
6. Cadenas que aparecen como ** string ** En la UI carecen de traducciones. Estos deberán agregarse a los archivos de traducciones ubicados en src/i18n/ . Algunas cadenas se generan dinámicamente y solo pueden aparecer en ciertas situaciones, por ejemplo, cuando se trata de eliminar un modelo. Nota: El flujo de trabajo de traducción debe cambiar en algún momento el uso de I18Next a favor de d2.i18n .

Casos extra especiales

Ciertos modelos requieren personalización más allá de lo posible utilizando la configuración y las anulaciones de campo. En esos casos, puede ser necesario crear un nuevo componente de nivel superior y asociar ese componente con una ruta especial en src/router.js

Ejemplos de este enfoque incluyen:

• Editor de programas de eventos: src/EditModel/event-program/EditEventProgram.component.js
• Editor de formulario personalizado: src/EditModel/EditDataEntryForm.component.js