johanjof wrote:Personnellement étant un adept de Slackware qui cherche à tout maîtriser j'aurais tendance à vouloir descendre au plus bas donc au niveau classe, qui aussi permet de ne pas regénerer inutilement un paquet d'éléments d'un artefact qu'on n'a pas modifié.
Je ne suis pas certain de vous suivre, mais les générateurs de code ne modifient pas les fichiers inutilement, la génération se fait d'abord en mémoire et les fichiers ne sont écrasés que si le contenu a changé
johanjof wrote:Mais il faut être plutôt pragmatique :
- aujourd'hui il existe quand on clique sur une classe l'option "roundtrip", il faut utiliser la même logique que sur cette option pour roundtrip body, sinon ça va perturber l'utilisateur
Cela veut dire qu'il faut suivre l'option 2 : si vous avez deux classes associées à un artefact et qu'il y a eu des modifications pour ces deux classes dans les sources alors un roundtrip au niveau artefact mettra à jour les deux classes, par contre si vous lancez le roundtrip au niveau d'une des deux classes alors seule celle-ci est mise à jour et pas l'autre.
La règle par défaut c'est que l'application d'une commande ou d'un plug-out à un élément donné n'impacte que cet élément et éventuellement ses sous éléments et éléments liés, c'est donc ce que fera le roundtrip body. La génération de code est un contre exemple, mais cela à un sens puisque le but est quand même de produire un/des sources, donc le faire pour toutes les classes associées à un artéfact et non pour la seule classe ou la génération est appliquée est raisonnable. Le verrou sera un autre contre exemple.
Je suis d'accord avec vous et je vais donc suivre l'option 2 pour le roundtrip body, même si cela alourdit celui-ci au niveau implémentation et donc exécution
johanjof wrote:Il me semble qu'à bien y réfléchir il faut se poser la question fondamentale de ce que l'on veut faire faire au concept des artefacts...
En ce qui me concerne c'est clair, mon interrogation n'était pas véritablement liée au cas des artéfacts mais portait sur les effets collatéraux et aurait été la même pour un autre type d’élément dans un cas semblable.
johanjof wrote:... (je préfèrerais d'ailleurs lors de la création d'une nouvelle classe avoir un bouton droit qui me permette de choisir l'artefact associé s'il existe déjà, mais ça c'est une autre nouvelle fonctionnalité pour un autre topic

)
j'ai répondu, et là nous ne sommes pas d'accord
johanjof wrote:- en +, je me rend dans les artefacts uniquement si je veux faire des trucs "experts", c-a-d des choses pour lesquelles il est difficile de trouver une solution dans la partie conception comme faire passer des directives de preprocessing (car je préfère idéalement que tout passe dans les vues, ...).
Je fais de même
johanjof wrote:car ce qui est dans les artefacts n'est pas tout reversible que ce soit en reverse ou en roundtrip.
Oui en ce qui concerne C++ car je saute toujours ce qui n'est pas modélisable en UML (les
friends dans les classes ne sont cependant pas perdus et sont supportés par les
extra class members)
Par contre les reverse/roundtrip Php ne perdent plus aucune forme non modélisable en UML et les mémorisent via les
extra artifact definitions que j'ai ajouté dans la version 7.1
Je pourrais donc faire de même lors des reverse/roundtrip C++ et mémoriser les parties non modélisables via des
extra artifact definitions ou des
extra class members, mais le reverse/roundtrip est déjà une sacrée usine à gaz