analysesi team mailing list archive

[Loïc Dreux <loic.dreux@xxxxxxxxx>]

Bonjour,

Effectivement tu as fait pas mal d'améliorations. Pour le moment je
suis en we à Berck pour les cerf-volant, dès lundi je vais te créer un
compte pour que tu puisses commiter.

Bon we a vous,

Loic


Le 17/04/09, Benjamin Gandon<benjamin.lp@xxxxxxxxxx> a écrit :
> Hello Loic, hello tout le monde,
>
> Enormément de travail, en effet je m'en rends compte après être rentré dans
> le code.
> Je vous fait un résumé de ce que j'ai déjà réussi à faire.
>
> Au niveau d'Analyse SI Hibiscus :
>
>  - Nouveauté : j'ai créé un EditCellDialog pour modifier une entité (via
> l'EditCellAction qui est dans le menu popup). Le code commun avec
> AddEntityDialog a été déplacé dans une nouvelle classe AbstractCellDialog.
>
>  - Dans AbstractCellDialog, j'ai fini le code pour RemoveAttributeAction et
> j'ai ajouté une table des attributs existants dans l'onglet "Attributs
> existants" et je lui ai associée une nouvelle AddExistingAttributeAction. Le
> layout de l'onglet "Attributs existants" est encore rudimentaire, mais ça
> marche déjà bien !
>
>  - Amélioration : le MeriseObjectTableModel est maintenant un MCDListener
> qui n'écoute que le MeriseObject qui l'intéresse. Avant il était un
> DictionaryListener et il risquait (même si c'était pas forcément le cas)
> d'être prévenu de tous les changements de tous les Attribute du Dictionnary.
>
>  - Amélioration : le MCD ne transmet plus directement se propre liste de
> MCDListener à MeriseObject : cette simplification commençait à être
> bloquante pour permettre d'écouter les changements d'un seul MeriseObject au
> lieu d'écouter systématiquement tous les changements de tous les
> MeriseObject du MCD. Maintenant, la classe MCD écoute elle-même tous ses
> MeriseObject et re-transmet les évènements qu'ils émettent aux MCDListener
> qui se sont inscrit chez elle.
>
> Je pense qu'il y a un peu la même amélioration à faire dans
> DefaultGraphModel, qui enregistre ses GraphModelListener (en l'occurrence,
> il n'y a que Graph) auprès de toutes ses Cell. Si jamais DefaultGraphModel
> devait enregistrer de nouveaux GraphModelListener alors qu'il possèdes déjà
> des Cell, ce nouveau GraphModelListener ne serait inscrit qu'auprès des
> nouvelles Cell et pas des anciennes.
>
> D'ailleurs, Graph peut bien écouter toutes les Cell par ce mécanisme, ce
> n'est plus très intéressant pour McdGraph puisqu'il écoute déjà le MCD, qui
> maintenant écoute toutes ses Entity.
>
>  - Ajout : un MCDListener peut maintenant recevoir un
> meriseObjectAttributeChanged().
>
>  - Amélioration : utilisation de Set à la place de List dans le modèle
> MCD... Pour permettre d'effacer une sélection du contenu d'un Set à partir
> d'un tableau d'indices, j'ai fait un nouveau type SubSetIterator qui s'avère
> bien utile.
>
>  - Petite amélioration : j'ai fait apparaître des fireXXX() partout où on
> envoyait des évènements, ça permet de mieux voir quel type d'évènements sont
> effectivement envoyés par une classe donnée (les fireXXX() se distinguent
> facilement dans la vue "Outline" d'Eclipse)
>
> Et puis j'ai eu une petite surprise avec l'AttributeValidator : il n'accepte
> pas les caractères "_" dans les noms des attributs :-)
>
>
> Au niveau d'EGT :
>
>  - Optimisation : j'ai placé les dimensions (largeur & hauteur) des cellules
> dans la classe Cell. Les dimensions ne sont calculées que quand le contenu
> de la cellule change (l'évènement suit ce parcours : Attribute -> Entity ->
> MCD -> McdGraphModel -> McdGraph) et non plus à chaque fois qu'on cherche
> une cellule. Le résultat du calcul est en quelque sorte "mis en cache" dans
> Cell et mis à jour uniquement si nécessaire (évènement cellChanged() dans
> Graph). Ca optimise (dans Graph) la recherche d'une cellule en un point
> donné du graphique. Pour rendre l'ensemble cohérent, GraphModelListener
> accepte un nouvel évènement cellResized() : cellChanged() met à jour la
> taille de la cellule grâce au bon CellRenderer, puis cellResized()
> raffraichit le graphique.
>
>
> Enfin bref, pas mal de boulot, c'est vraiment sympa de rentrer dans un code
> bien pensé !
>
> Pour le SVN, ça va commencer à être vraiment utile que je puisse commiter :
> ce serait dommage d'avoir des conflits à gérer. Tu va pouvoir me faire un
> accès ? Tu veux que je te fournisse une clé SSH publique ?
>
> A bientôt
>
>
>
> Loic Dreux a écrit :
>>
>> Le jeudi 16 avril 2009 à 16:08 +0200, Benjamin Gandon a écrit :
>>>
>>> C'est bon, je m'en suis sorti avec Maven, j'ai pu tester l'appli !
>>> Je vois qu'il y reste un peu de boulot sur l'interface... mais c'est
>>> bien. Vraiment bien.
>>
>> s/un peu/énormément/ig ;)
>>>
>>>
>>> Pour les types des champs (MCD), je vois que l'interface propose les
>>> types du dialecte SQL final. Du coup, on doit choisir le "dialecte" SQL
>>> dès la création du modèle et on ne peut plus revenir sur ce choix.
>>
>> Effectivement, après réflexion par rapport aux erreurs de la 0.6.x, je
>> voulais pouvoir utiliser plusieurs dialectes SQL différents et pour le
>> moment, le choix se fait au départ et ne plus être changé. Il faut dire
>> que j'aimerai bien ajouté l'ingénierie inversé (j'ai déjà fait quelques
>> développement la dessus) et pour cette fonctionnalité, le SGBG compte
>> énormément : on ne peux pas faire de l'ingénierie inversé sur du MySQL et
>> migrer facilement vers du PostgreSQL. Il faudrait peut-être ajouter un
>> fonctionnalité qui permet de passer d'un model pour un SGBD spécifique au
>> model SGBD générique. Solution à étudier
>>>
>>>
>>> Au niveau MCD je pensais plutôt judicieux d'utiliser des types plus...
>>> "conceptuels". Ces types seraient indépendants du dialecte SQL choisi
>>> pour le MPD. Ces types "conceptuels" seraient donc convertis (genre, une
>>> table de conversion) en types SQL, mais tout à la fin. Lors de la
>>> conversion MLD->MPD. On aurait donc une table de conversion pour chaque
>>> dialecte SQL. Pour faire simple au début, on prendrait les types mysql,
>>> mais au moins le mécanisme interne serait déjà là pour le futur. Cette
>>> manière de faire serait plus pérenne : elle permettrait d'utiliser un
>>> même modèle pour générer au choix, une base mysql ou postgresql. Avais-tu
>>> toi aussi pensé à ça ?
>>
>> J'y ai effectivement pensé mais c'est gênant pour ceux qui veuille
>> utiliser un SGBD spécifique et utilisant tous les types de données. En
>> utilisant un model générique que l'on convertirait in fine en model SGBD
>> spécifique, on se restreint aux types données en communs à moins d'ajouter
>> une phase de conversion des types de données génériques au types de
>> données spécifique où l'utilisateur devra lui-même faire des choix de
>> conversion.
>> A chaud, je dirais qu'il faudrait développer des outils de migrations
>> model pour un SGBD spécifique <-> model pour le SGBD générique mais je ne
>> sais pas vraiment comment mettre ça en place, ça risque d'apporter
>> énormément de modification au code existant.
>>>
>>>
>>> J'avais aussi pensé que de manière générale, le choix de produire une
>>> base de données relationnelle (ou hiérarchique, ou objet) se ferait au
>>> moment de créer le MLD. Dans le cas d'un un MLD relationnel, le choix du
>>> dialecte SQL (et des optims) se ferait au moment de générer le script SQL
>>> (qui est en fin de compte le MPD).
>>>
>>> Dans l'absolu, rien n'interdirait de générer du XSD (via un MLD
>>> hiérarchique par exemple) ou du SQL (avec le MLD relationnel actuel) à
>>> partir d'un même MCD, si cela est possible. J'ai vu que tu as pensé à des
>>> greffons. Je ne sais aps jusqu'où tu as poussé la réflexion. Mais ça
>>> pourrait être intéressant dans l'optique de rajouter des nouveaux types
>>> de MLD et des nouveaux types de MPD. Qu'en penses-tu ?
>>
>> Pour les greffons, actuellement j'ai commencer à développer ceux pour
>> Oracle et Mysql, je me limite aux SGBD relationnel mais rien n'empêche de
>> voir beaucoup plus loin.
>>
>> Tes idées sont très bonnes, si tu veux essayer de schématiser tout ça je
>> suis preneur.
>>>
>>>
>>>
>>>
>>> Loïc Dreux a écrit :
>>>>
>>>> Pour maven, tu peux récupérer les projets "egt" et "version" de la même
>>>> manière que analysesi :
>>>> http://zobi.homelinux.org/egt/
>>>> http://zobi.homelinux.org/version/
>>>>
>>>> Si le projet "version" est finalisé et ne devrait plus bouger, "Egt" est
>>>> toujours en travaux surtout sur la partie Graph, il faut voir ce projet
>>>> comme une extension d'AnalyseSI, en gros j'ai mis dans Egt tout ce qui
>>>> pouvait être réutilisé dans un autre projet Swing. Pour les autres
>>>> paquets, tu peux utiliser le repository maven :
>>>> http://zobi.homelinux.org/repo/
>>>>
>>>> Pour tes remarques sur le design du MCD, c'est surtout Yann D'ISANTO
>>>> <ydisanto@xxxxxxxxx> qui avait fait un très bon travail à l'époque et je
>>>> n'ai pas beaucoup retravailler sur le model depuis, personnellement je
>>>> préfère surtout développer sur la partie interface Swing donc n'hésite
>>>> pas à faire des modifications (comme remplacer les List par des Set) et
>>>> je les mergerai dans le tronc par la suite.
>>>>
>>>> Pour le choix de XStream, je n'ai malheureusement pas beaucoup
>>>> travailler sur la partie sauvegarde, j'ai juste poser quelques briques
>>>> de base qui devront surement être pas mal retouchées. C'est la partie
>>>> qui m'inquiète le plus car je me demande comment gérer les évolutions
>>>> tout en gardant une compatibilité avec le format de sauvegarde. Si tu
>>>> connais bien cette bibliothèque, n'hésite pas à faire évoluer mon code.
>>>>
>>>> Dès que tu as récupérer toutes les sources et réussi à compiler le
>>>> projet, fais le moi savoir je vais te créer un compte pour que tu
>>>> puisses ajouter tes modifications.
>>>>
>>>> Le 16 avril 2009 12:06, Benjamin Gandon <benjamin.lp@xxxxxxxxxx> a écrit
>>>> :
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>>> Pour le long terme, j'ai décidé de repartir de zéro car le code actuel
>>>>>> (0.6.x) est vraiment ancien et fait à l'arrache pendant mes études
>>>>>
>>>>> Le fait que c'est du code d'étudiant, oui ça ne pouvait pas m'échapper
>>>>> :-)
>>>>>
>>>>>
>>>>>> mais repartir de zéros demande vraiment de travail
>>>>>
>>>>> C'est bien ce dont je me rends compte ! Ca fait beaucoup de choses à
>>>>> revoir en effet, mais c'est la seule solution pour aller plus loin.
>>>>>
>>>>>
>>>>>
>>>>>> j'ai créé un utilisateur anonymous/anonymous qui devrait fonctionner
>>>>>
>>>>> Ok, anonymous/anonymous fonctionne.
>>>>>
>>>>>
>>>>>
>>>>>> Si tu es intéressé pour m'aider sur le développement de la version de
>>>>>> dev Hibiscus, je peux te créer un nouvel utilisateur.
>>>>>
>>>>> Oui tu peux y aller. Si je continue sur la version 0.6, je vais finir
>>>>> par tout réécrire... pour arriver à qqch de proche de ta version :-)
>>>>>
>>>>>
>>>>>> Il faudra réfléchir sur la gestion de cette branche : soit la laisser
>>>>>> en hébergement chez moi ou la passer en partie sur launchpad.
>>>>>
>>>>> En attendant, je peux très bien "commiter" dans une branche pour moi et
>>>>> on discute après pour les éventuels "merge" vers le "trunk". Ta version
>>>>> est bien avancée, ça devrait pas me prendre des siècles pour faire le
>>>>> MLD relationnel (on pourra même envisager d'autres MLD plus tard) et la
>>>>> conversion. J'aimerais bien avoir des options aux différents étages de
>>>>> conversion. Par exemple, choisir de créer ou non des "surrogate key" au
>>>>> moment de générer le MLD (utile pour les relations N-N avec Hibernate)
>>>>> ou choisir quelles clés étrangères on retient dans le MPD.
>>>>>
>>>>> Il me manque quelques artifacts pour Maven :
>>>>>>
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> org.hibiscus:egt:jar:1.1-SNAPSHOT:compile
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> net.java.dev.xhtmlrenderer:core-renderer:jar:7.0:compile
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> net.java.dev.xhtmlrenderer:minium:jar:7.0:compile
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> org.hibiscus:substance:jar:1.0:compile
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> org.hibiscus:substance-extras:jar:1.0:compile
>>>>>> 16/04/09 11:32:04 CEST: Missing artifact
>>>>>> org.hibiscus:swingx:jar:1.0:compile
>>>>>
>>>>> je peux les trouver où ?
>>>>>
>>>>> Sinon, petite lecture rapide du code pour le modèle MCD...
>>>>>
>>>>> Le design est nickel.
>>>>> Juste, dans ma version j'ai utilisé des Set<Attribute> dans
>>>>> MeriseObject au lieu de List<Attribute> pour assurer l'unicité.
>>>>> J'utilise LinkedHashSet pour conserver l'ordre d'insertion. D'autant
>>>>> plus que tu as (toi aussi :-) ) surchargé equal() et hashcode() pour
>>>>> qu'ils se basent uniquement sur le "name". Moi aussi j'ai doublement
>>>>> lié MeriseObject et Attribute. Mais j'en ai profité pour ajouter la
>>>>> prise en compte du "meriseObject" dans mes equal() et hashcode(), ce
>>>>> qui est assez logique en somme : unicité pour un nom donné dans un
>>>>> objet donné.
>>>>>
>>>>> Dans MCD, j'aurais aussi mis des Set<Entity> et Set<Relation> (toujours
>>>>> avec LinkedHashSet par derrière) puisqu'on n'est pas sensé en avoir en
>>>>> double... mais je te laisse me dire ce que tu en penses.
>>>>>
>>>>> Très bien le choix de XStream.
>>>>>
>>>>> Vraiment plein de bonnes choses en somme. Exactement la base de code
>>>>> dont je rêvais :-)
>>>>>
>>>>> A bientôt
>>>>>
>>>>>
>>>>>
>>>>> Loic Dreux a écrit :
>>>>>>
>>>>>> Le jeudi 16 avril 2009 à 09:58 +0200, Benjamin Gandon a écrit :
>>>>>>>
>>>>>>> Hello Loïc,
>>>>>>>
>>>>>>> C'est intéressant le nouveau graphe d'objets pour modéliser le MCD.
>>>>>>> C'était la première chose à revoir dans le code. C'est même
>>>>>>> précisément cet objectif que je me suis fixé dans la branche
>>>>>>> expérimentale ~benje/analysesi/exp10... Mais je ne savais pas que tu
>>>>>>> travaillais aussi là-dessus ! et c'est un peu dommage de faire le
>>>>>>> même boulot chacun dans son coin, non ?
>>>>>>
>>>>>> Tout à fait ! En fait quand Bruno m'a contacté pour reprendre en main
>>>>>> le projet, je lui avais déjà parlé de cette nouvelle branche mais il
>>>>>> m'a dit qu'il préférait faire avancer la branche 0.6.x pour régler les
>>>>>> bugs les plus gênants, ce qui est une excellente chose à court terme.
>>>>>> Pour le long terme, j'ai décidé de repartir de zéro car le code actuel
>>>>>> (0.6.x) est vraiment ancien et fait à l'arrache pendant mes études,
>>>>>> mais repartir de zéros demande vraiment de travail et ça fait 3 ans
>>>>>> que je travaille dessus par intermittence.
>>>>>>>
>>>>>>>
>>>>>>> En regardant la JavaDoc je vois que tu as déjà bien avancé, et sur
>>>>>>> des bases (effectivement) bien plus pérennes que l'ancien code ! Je
>>>>>>> vois aussi qu'il reste le MLD relationnel à faire et les algos
>>>>>>> (vérifs, transfos, etc) à mettre en œuvre. Est-ce qu'on peut avoir
>>>>>>> accès à ton code ? L'accès svn anonyme (http) ne marche pas, ça
>>>>>>> demande un mot de passe.
>>>>>>
>>>>>> L'accès anonyme ne fonctionne pas parce USVN ne permet pas de le
>>>>>> configurer (à ma connaissance). Par contre, j'ai créé un utilisateur
>>>>>> anonymous/anonymous qui devrait fonctionner, je vais écrire une
>>>>>> documentation sur le site du projet. Si ça ne fonctionne toujours pas,
>>>>>> fait le moi savoir.
>>>>>>>
>>>>>>>
>>>>>>> Et sinon, Hibiscus... heu... ça fait référence à la plante ?
>>>>>>> (mais c'est pas toi qui possèdes le domaine hibiscus.org, non ?)
>>>>>>
>>>>>>
>>>>>> Hibiscus fait bien référence à la plante, c'est juste un nom de code
>>>>>> pour la prochaine version. Je ne possède pas le domaine hibiscus.org
>>>>>> mais je pourrais poser un nom du genre hibiscus-project.org un jour
>>>>>> ;).
>>>>>>
>>>>>> Si tu es intéressé pour m'aider sur le développement de la version de
>>>>>> dev Hibiscus, je peux te créer un nouvel utilisateur. Il faudra
>>>>>> réfléchir sur la gestion de cette branche : soit la laisser en
>>>>>> hébergement chez moi ou la passer en partie sur launchpad.
>>>>>>
>>>>>> A bientôt
>>>>>>
>>>>>> Loïc Dreux
>>>>>>>
>>>>>>>
>>>>>>> A bientôt
>>>>>>> Benjamin
>>>>>>>
>>>>>>>
>>>>>>> Loic Dreux a écrit :
>>>>>>>>
>>>>>>>> Bonjour à tous,
>>>>>>>>
>>>>>>>> Je tenais déjà à féliciter Bruno pour la reprise du projet et les
>>>>>>>> mises
>>>>>>>> à jour successives qui sont sorties depuis le début de l'année, je
>>>>>>>> suis
>>>>>>>> avec intérêt les développements futur.
>>>>>>>>
>>>>>>>> Sinon, malgré l'annonce de l'arrêt du développement, il se trouve
>>>>>>>> que
>>>>>>>> j'ai pleins de temps disponible, du temps que je passe à développer
>>>>>>>> sur
>>>>>>>> la nouvelle branche Hibiscus. J'ai fait une demo pour ceux que ça
>>>>>>>> intéresse : http://blip.tv/file/1996981. Il est évident que cette
>>>>>>>> version n'est pas prête mais ces dernières semaines, j'ai avancé sur
>>>>>>>> pas
>>>>>>>> mal de points et le socle est beaucoup plus solide que les versions
>>>>>>>> 6.4.x.
>>>>>>>> J'héberge moi-même les sources de cette version pour les
>>>>>>>> développeurs
>>>>>>>> curieux à l'adresse http://zobi.homelinux.org/analysesi/.
>>>>>>>>
>>>>>>>> A bientôt
>>>>>>>>
>>>>>>>> Loïc Dreux
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
>>
>