Alors si ça me gère les points d'insertion du code, en sachant qu'entre tel endroit tel endroit il doit pas y toucher, très bien. Le problème peut venir de l'incapacité de l'outil de comprendre que telle zone de code ne fait pas partie de ce qu'il a généré, typiquement le coeur d'une fonction.
Acceleo fonctionne, comme ca. Nous on utilise OAW Xtend avec le même principe de balises protected
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
On est d'accord: un appel à 'une méthode qui a été renommée dans le modèle puis régénérée, ne ne sera pas mis à jour dans le corps de la méthode appelante alors que le refactoring s'en sortira mieux. Mais bon y'a pas mort d'homme. Pense que ton modèle une fois mis à jour te permettra aussi de mettre à jour d'autres briques qui ne seront pas couvertes par ton IDE. Par contre je ne vois pas le rapport avec RSM ou Clearcase là. tu compares un IDE avec un modeleur et un VCS
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption.
Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
Là tu t'en prends plus au modeleur mais d'une manière générale, il faut éviter de bosser sur les diagrammes et attaquer directement la structure du modèle, voire utiliser un DSL texte (qui n'est rien d'autre qu'un langage)
Avec RSM le truc chiant c'est que pour créer le moindre lien entre 2 concepts il faut un diagramme. C'est perfectible.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Alors si ça me gère les points d'insertion du code, en sachant qu'entre tel endroit tel endroit il doit pas y toucher, très bien. Le problème peut venir de l'incapacité de l'outil de comprendre que telle zone de code ne fait pas partie de ce qu'il a généré, typiquement le coeur d'une fonction.
Acceleo fonctionne, comme ca. Nous on utilise OAW Xtend avec le même principe de balises protected
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
On est d'accord: un appel à 'une méthode qui a été renommée dans le modèle puis régénérée, ne ne sera pas mis à jour dans le corps de la méthode appelante alors que le refactoring s'en sortira mieux. Mais bon y'a pas mort d'homme. Pense que ton modèle une fois mis à jour te permettra aussi de mettre à jour d'autres briques qui ne seront pas couvertes par ton IDE. Par contre je ne vois pas le rapport avec RSM ou Clearcase là. tu compares un IDE avec un modeleur et un VCS
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption.
Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
Là tu t'en prends plus au modeleur mais d'une manière générale, il faut éviter de bosser sur les diagrammes et attaquer directement la structure du modèle, voire utiliser un DSL texte (qui n'est rien d'autre qu'un langage)
Avec RSM le truc chiant c'est que pour créer le moindre lien entre 2 concepts il faut un diagramme. C'est perfectible.