Bonjour,
On 19/01/2012 17:33, MoYo wrote:
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.
Je pensais créer une classe Table qui gèrerait l'affichage de ce type de
table. C'est relativement compliqué, mais je devrais pouvoir proposer
quelque chose dans le courant de la semaine prochaine.
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.
Cela fait partie de la difficile équation à résoudre : il y a bijection
entre le NetworPort et son instanciation : un NetworkPort <=> une
instanciation. L'un n'existe pas sans l'autre.
Dans une première version, je me suis rendu compte qu'il était lourd de
charger un NetworkPort (par getFromDB ou autre), puis de faire une
recherche de l'ID de sont instantiation (SELECT id FROM
glpi_networkport??? WHERE networkports_id='?') pour enfin pouvoir
charger son instantiation (toujours getFromDB ou autre). J'ai, donc,
cherché une solution pour éviter d'avoir cette double recherche et
trouver directement l'instantiation d'une seule requête.
Une première solution est de mettre un "networkports_id" dans
l'instanciation et un "networkportinstantiations_id" dans le
NetworkPort. Comme cela, pour obtenir l'instanciation, il suffit de
chercher directement **
$networkport->fields['networkportinstantiations_id'] **. Mais qui de
l'oeuf ou de la poule est le premier ? En effet, il faut gérer ce double
chaînage. De plus, cela oblige à charger le NetworkPort si l'on veut
avoir accès directement à son instantiation.
J'ai essayé de redéfinir la méthode CommonDBTM::getIndexName(). Mais il
y avait quelques effet de bord (des requêtes hors de CommonDBTM
utilisent directement `id` et non CommonDBTM::getIndexName()). C'est
pourquoi je suis parti sur la solution avec un id commun entre le
NetworkPort et son instanciation.
Je viens de voir que EntityData et TicketSatisfaction redéfinissaient la
méthode CommonDBTM::getIndexName(). Cela n'introduit-il pas trop de
problème ?
Mais cela risque de devenir caduque si on change de point de vue sur la
gestion des différentes instanciations.
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).
Hormis l'adresse MAC et la carte réseau physique associée (mais cela ne
concerne que Wifi et Ethernet pour le moment), je ne vois pas quels sont
les autres informations que nous pourrions centraliser.
L'alternative initiale de vraiment tout migrer dans networkports me
semble aussi une solution viable malgré les contraintes sur
l'évolutivité que tu exposais.
C'est l'une des solutions de l'équation brièvement esquissée ci-dessus.
Cela semble plus robuste et plus simple. Mais les évolutions futures
seront plus lourdes à faire.
Avec une classe par type d'instantiation, cela permet de faire le ménage
dans la classe NetworkPort et de gérer plus finement chaque type de port
(méthodes spécifiques pour le Wifi, pour le port Ethernet, pour
l'aggrégat, ...).
De plus, une idée que je n'ai pas osé mettre en oeuvre (tiens, j'ai été
frileux sur ce coup :D) était de faire le même type de découpage avec
les carte réseau : DeviceWifiNetworkCard, DeviceEthernetNetworkCard, ...
Ainsi, une partie des champs disponibles pour les cartes réseaux serait
"adaptable" dans l'instanciation (une carte réseau Ethernet 10/100/1000
verrait l'instanciation du NetworkPort configuré en 10, 100 ou 1000).
En conclusion : l'équation <modularité, robustesse, facilité
d'utilisation et de maintenance, ...> est difficile à résoudre. Dans
cette première implémentation, je l'ai pris sous un certain point de
vue. On peut changer d'angle de vue, pourvu qu'il soit justifié.
Damien
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
