> lorente a écrit > perso, je dirait que le probleme vient peut etre de la construction actuelle de glpi... > >Si glpi etait plus modulaire, on aurait pas ce probleme de "trop de >fonctionnalités", car on pourrait activer a l'affichage seulement ce que l'on > desire... > >Si glpi etait plus modulaire, les personnes interessées pourraient creer un >module a part pour gerer les services par exemple... > >Je sais je fais revoir beaucoup trop de chose par ce commentaire... mais voila mon avis...
Bonsoir, Nous sommes tout à fait conscient que l'ajout de focntionnalités devient un problème pour la lisibilté au sein de GLPI. Mais nous sommes trop bons et nous n'allons pas arrété d'inclure des features qui nous sont demandés et qui semblent intéressantes ;) Nous nous sommes posés le problème pour la 0.5 et nous avons evoqué deux solutions à ce problème. Chacune étant assez simple à mettre en place sachant que les deux ne sont pas incompatibles : 1 - Mettre en place un système d'onglets au niveau des différentes fiches pour les alléger. Par la même cela crée un optionnage virtuel car vous n'allez que sur les onglets qui vous intéressent. 2 - Un optionnage des différentes features pour alléger l'interface des features non utilisées. Nous n'étions pas forcèment d'accord sur quelle solution a adoptée mais vu qu'elles n'étaient pas incompatibles nous avons mis en place (hier soir et ajourd'hui) la solution 1 dans un premier temps. Pour ma part j'etais plus pour la deuxieme solution mais en voyant le résultat obtenu aujourd'hui je me dis que l'optionnage n'est quasiment plus nécessaire même s'il peut encore permettre d'allèger l'interface. La mise en place de l'optionnage des features est assez simple à mettre en place dans GLPI vu que le code est déjà très modulaire. Si nous avons des retours la dessus après la sortie de la v0.5 je pense que nous le mettrons en place car ce n'est pas quelquechose qui demandera beaucoup de temps et qui pourra servir le plus grand nombre. Pour revenir au problème initial, le problème des services n'est pas trop un problème d'interface ou de feature supplémentaire mais clairement de conception. Nous ne voulons pas partir sur une solution non logique au niveau de la base de données car le retour en arrière risque d'être plus que difficile à réaliser. A l'heure actuelle c'est l'évolution de la base de données vers une architecture la plus logique possible qui nous prend le plus de temps. Au final, plus la base est seine au niveau de sa structure, plus son évolution et l'ajout de nouvelle feature en sera facilité. Bref au final la dissociation software/service ne nous semblent pas logique car un service n'est qu'un logiciel (programme/exécutable) qui écoute sur un ou plusieurs ports spécifiques. Mais ce n'est pas la vision de tout le monde. C'est pour cela que nous aimerions avoir d'autres avis pour trancher ce problème ;) 1 - service = software qui écoute sur un ou des ports spécifiques ou 2 - service != software voili voilo je vous laisse à cette petite discussion pendant mon Week-end prolongé. Bon Week-End à tous. Julien
