maintenance app

App de manutenção

App Config

O aplicativo de manutenção é amplamente acionado pela configuração do aplicativo e pelos esquemas da API. Os esquemas são lidos diretamente da API (por D2). Os seguintes documentos a configuração do aplicativo:

• dentro de src/config/ ...
  • maintenance-models.js define os tipos de modelo que são mostrados no aplicativo
  • field-config/ contém a configuração de cada tipo de modelo
    • field-order.js define a ordem dos campos dentro do formulário para cada tipo de modelo
    • field-groups.js define o agrupamento de campo para o formulário para cada modelo. Atualmente, isso é usado apenas para o ProgramRules, mas pode ser uma boa idéia expandi -lo para outros tipos de modelo também.
  • field-overrides/ contém configuração extra para campos que requerem comportamento não padrão. Mais comumente, isso significa campos que exigem componentes especiais.
    • index.js lista todos os modelos que têm uma ou mais substituições de campo
    • As substituições de campo reais são especificadas em arquivos nomeados após cada tipo de modelo, que por sua vez são importados para index.js . Alguns tipos de modelos ou campos que exigem muita lógica são separados em sub -pastas.
  • inlinehelp-mapping.json especifica o mapeamento de cada seção/tipo de modelo para as páginas da documentação.
  • field-rules.js contém lógica condicional que pode ser usada para mostrar ou ocultar campos ou definir valores de campo com base no valor de outros campos.
  • periodTypes.json contém a lista de tipos de período suportados pela versão atual da API.
  • disabled-on-edit/ contém arquivos que listam campos que sempre serão exibidos como somente leitura quando um objeto estiver sendo editado.
    • index.js Importa listas de nomes de campo de arquivos nomeados após cada modelo relevante

Para o registro, "esquemas" e "tipos de modelos" são essencialmente a mesma coisa e esses termos são usados ​​de forma intercambiável tanto no aplicativo de manutenção quanto em outros lugares. Os esquemas são expostos pela API, mas nem todo tipo de modelo está listado nos esquemas. Para adicionar à confusão "modelos" também são algumas vezes chamados de "objetos".

Seções, tipos de modelo e campos

Para que um tipo de modelo apareça no aplicativo de manutenção, as seguintes condições precisam ser atendidas:

• O tipo de modelo está listado em uma seção em src/config/maintenance-models.js
• O tipo de modelo existe no ponto final dos esquemas na API

Depois que essas condições forem atendidas, o tipo de modelo será exibido no aplicativo de manutenção na seção especificada em maintenance-models.js . Ao criar ou editar modelos do novo tipo, o formulário contém apenas um punhado de campos predefinidos. Para que os campos adicionais sejam mostrados no formulário, as seguintes condições precisam ser atendidas:

• O campo está listado sob o tipo de modelo em src/config/field-config/field-order.js
• O campo existe no ponto final dos esquemas para o tipo de modelo específico na API.

Adicionando um novo tipo de modelo

Adicionar um novo modelo à manutenção normalmente envolve as seguintes etapas:

1. Adicione o tipo de modelo a src/config/maintenance-models.js
2. Adicione o tipo de modelo e a lista de campos que devem ser mostrados no formulário para src/config/field-config/field-order.js
   1. (Opcional) Se os campos devem ser separados em grupos separados no formulário, os grupos poderão ser especificados no src/config/field-config/field-groups.js .
3. O novo tipo de modelo agora deve ser listado no aplicativo de manutenção. Navegue até o novo tipo de modelo e verifique o formulário ao criar uma nova instância do tipo de modelo e ao editar uma instância existente. Se você tiver sorte, tudo funcionará neste momento. É mais provável que haja um ou mais campos que requerem maior personalização.
4. Crie um novo arquivo com o nome do novo tipo de modelo em src/config/field-overrides/ . Abra src/config/field-overrides/index.js , importe o arquivo recém-criado e adicione-o ao objeto overridesByType .
5. Dentro do novo arquivo de substituição de campo ( src/config/field-overrides/newType.js ), comece a adicionar personalizações para os campos que o exigem. Isso normalmente envolve a criação de novos componentes e/ou substituir determinadas propriedades do campo. Veja as substituições de campo existentes para exemplos.
6. Strings que aparecem como ** string ** na interface do usuário não têm traduções. Eles precisarão ser adicionados aos arquivos de traduções localizados no src/i18n/ . Algumas strings são geradas dinamicamente e podem aparecer apenas em determinadas situações, por exemplo, ao tentar excluir um modelo. NOTA: O fluxo de trabalho de tradução deve, em algum momento, mudar para o uso do i18Next em favor do d2.i18n .

Casos especiais extras

Certos modelos requerem personalização além do que é possível usando as substituições de configuração e campo. Nesses casos, pode ser necessário criar um novo componente de nível superior e associar esse componente a uma rota especial no src/router.js

Exemplos dessa abordagem incluem:

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