Le 19/01/2012 10:40, Damien Touraine a écrit :
Bonjour,
Je suis en train de travailler sur la représentation des NetworkPort
dans les équippements (ordinateurs et autres switchs). J'essaie
d'ajouter les informations réseaux et tout ce qui est nécessaire. Mais
je me heurte à une difficulté : j'ai une ligne de tableau par port.
Mais, pour chaque port, je peux avoir plusieurs nom réseau. Chacun de
ces noms réseau peut avoir plusieurs adresses IP avec ses informations
de réseau (adresse, masque et passerelle). De même, indépendemment de
l'adresse IP, chaque nom réseau peut avoir plusieurs alias.
L'idéal serait de faire du "rowspan". Mais pour cela, il faut pouvoir
pré-définir l'ensemble de la ligne afin de savoir, pour chaque élément
(nom réseau, adresse IP, alias) à chaque niveau quel est le nombre de
ligne qu'il occupe.
Une autre solution serait de créer un nouveau tableau à l'intérieur de
la cellule, mais les en-têtes ne plomberaient plus avec les cases des
sous-tableaux.
Salut,
dans un premier temps tu peux mettre effectivement un tableau dans la
cellule sans pour autant mettre d'entêtes dans les sous-tableaux.
Ces entêtes doivent pouvoir être positionnées dans celles du tableau
complet.
Une fois cela en place on pourra réfléchir à améliorer l'affichage.
Autre remarque sinon au niveau du schéma de la DB.
J'ai fait une analyse rapide et je pense qu'il y a des problèmes par
rapport aux conventions standards de GLPI.
Exemple pour la liaison networkports / networkportethernets. La liaison
entre ces 2 tables se fait quand les id sont identiques.
Cela ne correspond pas aux conventions de GLPI. L'id devrait rester en
autoincrément et donc non forcé. On devrait avoir un champ
networkports_id pour faire la liaison entre les tables.
Sans cela on va avoir des problèmes au niveau du moteur de recherche.
Pour revenir sur un autre sujet discuté en interne, je penche de plus en
plus pour migrer les données qui semblent génériques dans networkports
(mac par exemple) et ne garder dans les tables liées uniquement les
éléments spécifiques aux types (non partagés par plusieurs types).
L'alternative initiale de vraiment tout migrer dans networkports me
semble aussi une solution viable malgré les contraintes sur
l'évolutivité que tu exposais.
++
Julien
Quelqu'un aurait-il une solution ?
Damien
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
