[XSL 1.2] Problème de parse sur les Exception dans Argo 0.30
Bonjour à tous, Il semble y avoir un changement de comportement entre la 0.30 et la 0.28 de ArgoUML sur les 'Signal' et 'Exception'. Les deux sont utilisés dans l'ObjectModel d'EUGene de la même manière, cad une exception sur une operation. Cependant ArgoUML semble avoir changé de stratégie, les 'Signal' ne peuvent plus être créé directement dans un package (dans l'arbre à gauche (peut-être un bug car le 'Signal' est disponible)). Par contre il est possible de créer une 'Exception' de cette manière alors que dans la précédente version cela ne marchait pas (ou pas avec EUGene). Argo permet aussi de créer un 'Signal' directement depuis une opération, mais cela semble couteux, car un 'Signal' différent (portant le même nom) pour chaque opération. Apparemment c'était l'inverse dans la précédente version qui ne permettait de créer que des 'Exception' par ce biais. Du coup le XSL actuel parse différemment les 'Signal' des 'Exception', pour un 'Signal' aucun problème il le prend comme étant directement dans un package, par contre pour une 'Exception' il utilise le package de l'opération qui la contient. Ça fou la grouille car maintenant le dernier ArgoUML ne permet plus de créer des 'Exception' depuis une opération mais que dans un package ! J'espère avoir été explicite sur le problème, le comportement semble inversé d'une version à l'autre d'Argo. Je préconiserais l'utilisation des 'Exception' ou 'Signal' depuis les packages et non plus directement dans les opérations. Cela résoudrait le problème car pour un ancien modèle ou un nouveau le parse des deux serait le même. Ticket : http://nuiton.org/issues/show/659 -- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com Membre du Réseau Libre-entreprise
On 03/06/2010 19:08, Florian Desbois wrote:
Bonjour à tous, Bonjour, Il semble y avoir un changement de comportement entre la 0.30 et la 0.28 de ArgoUML sur les 'Signal' et 'Exception'. Les deux sont utilisés dans l'ObjectModel d'EUGene de la même manière, cad une exception sur une operation.
Cependant ArgoUML semble avoir changé de stratégie, les 'Signal' ne peuvent plus être créé directement dans un package (dans l'arbre à gauche (peut-être un bug car le 'Signal' est disponible)). Par contre il est possible de créer une 'Exception' de cette manière alors que dans la précédente version cela ne marchait pas (ou pas avec EUGene). J'ai rein compris :)
Voici une copie d'écran pour décrire le problème : - http://nuiton.org/attachments/167/exemple.png L'exception utilisée aujourd'hui est "IsisFishException" qui est en fait une classe qui contient une exception. L'utilisation devrait plutôt être celle de "IsisFishException2". Et comme, le dit florian, avec ArgoUml 0.30, il est impossible de remodeliser IsisFishException. -- Éric<chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le vendredi 04 juin 2010 à 09:51 +0200, Eric Chatellier a écrit :
On 03/06/2010 19:08, Florian Desbois wrote:
Bonjour à tous,
J'ai rein compris :)
Vi c'est un problème compliqué à expliquer
Voici une copie d'écran pour décrire le problème : - http://nuiton.org/attachments/167/exemple.png
Finalement une bonne copie d'écran vaut mieux qu'une tirade maladroite :)
L'exception utilisée aujourd'hui est "IsisFishException" qui est en fait une classe qui contient une exception.
L'utilisation devrait plutôt être celle de "IsisFishException2".
Et comme, le dit florian, avec ArgoUml 0.30, il est impossible de remodeliser IsisFishException.
Et donc il faudrait faire les modifs sur les modèles concernés, car ce bug est bloquant actuellement sur un nouveau modèle, donc une régression dans EUGene 2.0.2 (enfin regression c'est un peu la faute d'ArgoUML)
-- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com Membre du Réseau Libre-entreprise
Le 04/06/2010 14:36, Florian Desbois a écrit :
L'exception utilisée aujourd'hui est "IsisFishException" qui est en fait une classe qui contient une exception.
L'utilisation devrait plutôt être celle de "IsisFishException2".
Et comme, le dit florian, avec ArgoUml 0.30, il est impossible de remodeliser IsisFishException. Et donc il faudrait faire les modifs sur les modèles concernés, car ce bug est bloquant actuellement sur un nouveau modèle, donc une régression dans EUGene 2.0.2 (enfin regression c'est un peu la faute d'ArgoUML
Tant que c'est annoncé clairement dans la version, c'est acceptable. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
participants (2)
-
Eric Chatellier -
Florian Desbois