Domaines de composition et transformations de domaines explicites

[JabX]

Fix #246

Cette PR contient beaucoup de breaking changes, désolé, mais c'est pour la bonne cause (promis).

asList: true > as: list

Le listDomain n'existe plus, il est désormais possible de définir plusieurs asDomains pour définir plusieurs transformations possibles sur une propriété du domaine. Ci-dessous, la migration de l'ancien vers le nouveau :

domain:
  name: DO_ID
  listDomain: DO_ID_LIST
---
class:
   name: DTO
   properties:
     - alias:
          class: Entity
          property: Id
       asList: true

devient

domain:
  name: DO_ID
  asDomains: 
    list: DO_ID_LIST
---
class:
   name: DTO
   properties:
     - alias:
          class: Entity
          property: Id
       as: list

Il est aussi possible de spécifier as sur une association, pour définir la transformation à utiliser pour les associations xxxToMany. Elle est renseigné à "list" par défaut pour correspondre au comportement existant.

Domaines de composition

kind n'existe plus sur les compositions, remplacé par domain au même titre que les autres types de propriétés. Son comportement est identique à l'usage existant de kind avec un domaine, sauf qu'il s'agit maintenant de la seule façon de définir le type de composition. Donc :

• object n'existe plus, il suffit de ne pas renseigner de domaine pour avoir une composition simple
• list n'existe plus, il faut maintenant renseigner un domaine explicite correspondant à l'implémentation de collection voulue à la place, comme si on voulait autre chose qu'une liste auparavant.

Types d'implémentation génériques

Il est désormais possible de renseigner genericType dans une implémentation de domaine, en plus de type. Ce champ peut référencer en plus des variables classique la variable spéciale {T}, qui correspond au type original de la propriété. Ce nouveau paramètre sera utilisé pour les 3 cas suivants :

• Lorsque le domaine est utilisé pour une composition, et la variable {T} vaut {composition.name}. Cet usage remplace l'utilisation de type existante pour les compositions (et ne rajoute plus un <{composition.name}> en fin de type si la variable n'était pas utilisée). Si genericType n'est pas renseigné pour l'implémentation du domaine, il vaudra "{T}". Un domaine utilisé pour une composition peut toujours être utilisé pour un autre type de propriété, il ne faudra pas oublier de renseigner la valeur de type (non générique).
• Lorsque la propriété utilisant la propriété est considérée comme une enum par la configuration du générateur. Elle vaut également "{T}" par défaut, {T} correspondant à la représentation de l'enum dans le langage cible. On ne voit pas vraiment de raison de surcharger cette valeur mais elle a été incluse pour l'exhaustivité 😄
• Lorsque le domaine est utilisé dans une transformation de domaine (via as, donc les cas décrits dans le premier point de cette PR). Si genericType n'est pas renseigné dans ce cas, elle vaudra par défaut la valeur de type, ce qui veut dire qu'il faut nécessairement spécifier la transformation pour qu'elle soit réalisée. Auparavant, cela n'existait que pour asList: true (et les associations toMany), et chaque générateur implémentait en dur la transformation à réaliser sur le type original (impossible à débrancher, et souvent en ajoutant "[]" à la fin ou en mettant List<> autour). {T} référencera ici le type original (qui peut être une enum ou une association par exemple).

Par exemple, le domaine DO_CODE_LIST dans les exemples est maintenant défini ainsi, pour reproduire à l'identique le comportement existant :

---
domain:
  name: DO_CODE_LIST
  label: Code
  ts:
    type: string[]
    genericType: "{type}[]"
  csharp:
    type: string[]
    genericType: "{type}[]"
  java:
    type: List<String>
    genericType: List<{type}>
    imports:
      - java.util.List

Autres impacts

• Il n'est plus possible de spécifier des mappings entre compositions list et associations toMany. Puisque tout est désormais à la main de l'utilisateur, il n'est simplement plus possible de déterminer comment il faut faire le mapping, et on n'a pas trouvé de manière de le décrire dans le modèle (enfin, rien qui ne vaille le coup en tout cas à côté de simplement retirer la fonctionnalité)
• Il faut désormais spécifier le nom du type importé à la fin d'un import en JS dans un domaine. Par exemple, si je veux importer Page de @/types, il faut écrire @/types/Page. Le type était auparavant déduit du type renseigné dans l'implémentation (de façon très approximative en plus), ce qui n'est plus possible de faire vu la richesse du nouveau système.
• il faut spécifier un domaine pour list dans tmdgen OpenApi.

Pourquoi ?

• Spécifier d'autres transformations de domaines que list
• Personnaliser les types de collections utilisés dans le code généré
• Expliciter, homogénéiser et personnaliser les transformations de type réalisées par les générateurs
• Supprimer des choix arbitraires et des implémentations peu robustes de TopModel