0
votes

Mapstructeur: Utilisation du contexte dans l'argument de la source de @Mapping

Lorsque vous utilisez plusieurs arguments dans un @mapper, il semble que les arguments @Context sont inaccessibles

public interface MyMapper {

  @Mapping(target="target1", source="arg1.arg") //works
  @Mapping(target="target2", source="arg2") //works
  @Mapping(target="target3", source="arg2.arg") //works
  @Mapping(target="target2", source="context.arg") //NOT WORKING
  public MyTarget convert(Object arg1, Object arg2, @Context Object context);

}


1 commentaires

Pourquoi avez-vous besoin de passer un @Context et utilisez-le comme source? Pouvez-vous fournir un peu plus de contexte?


3 Réponses :


2
votes

Par définition A @Context objet annoté n'est pas une source. C'est du contexte pour que vous ne puissiez pas l'utiliser comme source dans le @ Mapping (cible = "cible2", source = "context.arg")

Voici un problème de GitHub associé avec réponse officielle: GitHub Issue


7 commentaires

Et comment atteindre le comportement souhaité alors?


Supprimer le @Context et montroptract le considérera comme un objet source. En marquant @Context Vous dites essentiellement à MODRUCTRUT d'ignorer le paramètre de mappage, mais transmettez-le dans les appels de méthode sous-jacents. De plus, bien que MapStructeur puisse gérer plusieurs arguments de source, il ne peut pas appeler plusieurs méthodes de paramètre source pour gérer les mappages imbriqués. L'API deviendrait imprévisible et le mécanisme de sélection serait venu à manifester.


Votre suggestion fonctionne si j'ai besoin de paramètre au même endroit. Mais si j'ai besoin de paramètre sur les deux couches, je devrai effectuer une carte (source source, param param, @Context paramam param) ce qui n'a aucun sens pour moi. Ce serait beaucoup plus facile de ne pas ignorer Paramètre de contexte pour la cartographie ..


La raison est indiquée dans mon commentaire ci-dessus. Cependant, vous pouvez coller à l'approche @context par délégation vers une deuxième méthode et un @AfterMapping .


Oui, j'ai vu cette approche quelque part dans la documentation officielle. Je ne comprends tout simplement pas pourquoi les créateurs ne veulent pas inclure le contexte dans la cartographie. Pourquoi ils l'excluent? Des idées?


Contexte == Par définition Contexte .. Pas un paramètre source. Son seul but est ignoré par la cartographie


Eh bien, c'est la définition de l'équipe de Mapstruit. Le contexte est quelque chose à utiliser comme contexte pour toutes les méthodes de la toute première méthode où elle est transmise. Pensez à un contexte de travail par lots ou à autre chose. La toute première classe qui a contemplé est passée comme argument est plus bienvenue pour lire ou mettre quelque chose au contexte. La question de MapStract est que l'argument de niveau supérieur ne peut pas être effectué de contexte dans le paramètre de contexte en aval et au contexte ne peut pas être utilisé comme source dans la première cartographie. Je comprends toutes les définitions et les contours de contournement, mais cela ne me convient pas. Merci pour une discussion précieuse, appréciez que



2
votes

Pour répondre à votre deuxième question:

public interface MyMapper {

  @Mapping(target="target1", source="arg1.arg")
  @Mapping(target="target2", ignore = true ) // leave to after mapping 
  MyTarget convert(Object arg1, @Context Object context);

  @AfterMapping
  default convert(Object arg1, @MappingTarget MyTarget target, @Context context) {
        target.setTarget2( convert ( context ) );
  } 

  // if you have multipe mappings, you could address them here
  @Mapping(target="target2", source="context.arg") 
  MyInnerTarget convert(Object arg1, Object context);
}


0 commentaires

0
votes

J'ai couru dans le même scénario que j'avais besoin d'un @Context param pour pouvoir passer à une fonction de mappage imbriquée, mais souhaitait également l'utiliser comme source dans un @ Mapping . J'ai pu atteindre cet article en utilisant expression comme suit: xxx


0 commentaires