maintenance app

maintenance-application

Configuration de l'application

L'application de maintenance est largement motivée par la configuration de l'application et les schémas de l'API. Les schémas sont lus directement à partir de l'API (par D2). Les documents suivants documentent la configuration de l'application:

• Dans src/config/ ...
  • maintenance-models.js définit les types de modèles affichés dans l'application
  • field-config/ Configuration de la configuration pour chaque type de modèle
    • field-order.js définit l'ordre des champs dans le formulaire pour chaque type de modèle
    • field-groups.js définissent le regroupement de champs pour la forme pour chaque modèle. Ceci n'est actuellement utilisé que pour les programmes, mais il pourrait être une bonne idée de l'étendre à d'autres types de modèles.
  • field-overrides/ contient une configuration supplémentaire pour les champs qui nécessitent un comportement non standard. Le plus souvent, cela signifie des champs qui nécessitent des composants spéciaux.
    • index.js répertorie tous les modèles qui ont un ou plusieurs surfaces de champ
    • Les remplacements de champ réels sont spécifiés dans les fichiers nommés d'après chaque type de modèle, qui à leur tour sont importés dans index.js . Certains types de modèles ou champs qui nécessitent beaucoup de logique sont séparés en sous-dossiers.
  • inlinehelp-mapping.json spécifie le mappage de chaque section / modèle de modèle aux pages de la documentation.
  • field-rules.js contient une logique conditionnelle qui peut être utilisée pour afficher ou masquer les champs ou définir des valeurs de champ en fonction de la valeur des autres champs.
  • periodTypes.json contient la liste des types d'époque qui sont pris en charge par la version actuelle de l'API.
  • disabled-on-edit/ Contient des fichiers qui répertorient les champs qui seront toujours affichés en lecture seule lorsqu'un objet est en cours de modification.
    • index.js importe des listes de noms de champ à partir de fichiers nommés d'après chaque modèle pertinent

Pour mémoire, les «schémas» et les «types de modèles» sont essentiellement la même chose et ces termes sont utilisés de manière interchangeable à la fois dans l'application de maintenance et ailleurs. Les schémas sont exposés par l'API, mais tous les types de modèle ne sont pas répertoriés dans les schémas. Pour ajouter à la confusion, les "modèles" sont également parfois appelés "objets".

Sections, types de modèles et champs

Pour qu'un type de modèle apparaisse dans l'application de maintenance, les conditions suivantes doivent être remplies:

• Le type de modèle est répertorié dans une section de src/config/maintenance-models.js
• Le type de modèle existe dans le point de terminaison des schémas dans l'API

Une fois ces conditions remplies, le type de modèle apparaîtra dans l'application de maintenance dans la section spécifiée dans maintenance-models.js . Lors de la création ou de l'édition de modèles du nouveau type, le formulaire ne contiendra par défaut qu'une poignée de champs prédéfinis. Pour que les champs supplémentaires soient affichés dans le formulaire, les conditions suivantes doivent être remplies:

• Le champ est répertorié sous le type de modèle dans src/config/field-config/field-order.js
• Le champ existe dans le point de terminaison des schémas pour le type de modèle spécifique dans l'API.

Ajout d'un nouveau type de modèle

L'ajout d'un nouveau modèle à la maintenance implique généralement les étapes suivantes:

1. Ajoutez le type de modèle à src/config/maintenance-models.js
2. Ajoutez le type de modèle et la liste des champs qui doivent être affichés dans le formulaire à src/config/field-config/field-order.js
   1. (Facultatif) Si les champs doivent être séparés en groupes séparés dans la forme, les groupes peuvent être spécifiés dans src/config/field-config/field-groups.js .
3. Le nouveau type de modèle doit désormais être répertorié dans l'application de maintenance. Accédez au nouveau type de modèle et vérifiez le formulaire à la fois lors de la création d'une nouvelle instance du type de modèle et lors de la modification d'une instance existante. Si vous avez de la chance, tout fonctionnera à ce stade. Il y aura plus probablement un ou plusieurs champs qui nécessiteront une personnalisation supplémentaire.
4. Créez un nouveau fichier nommé d'après le nouveau type de modèle dans src/config/field-overrides/ . Ouvrez src/config/field-overrides/index.js , importez le fichier nouvellement créé et ajoutez-le à l'objet overridesByType .
5. À l'intérieur du nouveau fichier de remplacement de champ ( src/config/field-overrides/newType.js ), commencez à ajouter des personnalisations pour les champs qui le nécessitent. Cela implique généralement de créer de nouveaux composants et / ou de remplacer certaines propriétés de champ. Regardez les remplacements de champ existants pour les exemples.
6. Les chaînes qui apparaissent comme ** string ** dans l'interface utilisateur manquent les traductions. Ceux-ci devront être ajoutés aux fichiers de traduction situés dans src/i18n/ . Certaines chaînes sont générées dynamiquement et ne peuvent apparaître que dans certaines situations, par exemple lorsque vous essayez de supprimer un modèle. Remarque: Le workflow de traduction devrait à un moment donné changer pour utiliser i18Next en faveur de d2.i18n .

Cas spéciaux supplémentaires

Certains modèles nécessitent une personnalisation au-delà de ce qui est possible en utilisant les remplacements de configuration et de champ. Dans ces cas, il peut être nécessaire de créer un nouveau composant de haut niveau et d'associer ce composant à un itinéraire spécial dans src/router.js

Des exemples de cette approche comprennent:

• Éditeur du programme d'événements: src/EditModel/event-program/EditEventProgram.component.js
• Éditeur de formulaire personnalisé: src/EditModel/EditDataEntryForm.component.js