Projet partagé d'un gestionnaire de réseau

[DDEFF]

Merci Pierre,

Je vote sans hésitation pour le 2ème choix : des objets externes au JSON. Même si je les maitrise mal, je les maitriserai certainement mieux que des objets dans le json.

Je vois aussi des "hashmap" au lieu de boucles "for". Ce serait plus rapide ?
J'ai pas mal de choses à apprendre...

Tu vois ce qui fais tourner en rond mon programme ?

A suivre
Denis

[Pierre59]

Les hashmaps c'est assez efficace, c'est presque aussi rapide que de l'indiceage, mais pour des tables. revers de la médaille il faut manipuler des hashcodes (il y a de bibliothèques pour cela).

Il faudrait commencer par enlever de ton programme tout ce qui ne sert pas (et y il en a beaucoup), laisser juste la lecture et la recherche des éléments, enlever peut être aussi pour l'instant les menus et les fullscreen, ..., on lit un fichier Json juste pour faire des essais.

Et on va commencer à faire des tableaux (voire des arraylist) avec des instances des éléments : zones, aiguilles, signaux, ...

Pierre

[Dominique]

soit on instancie tous les objets trouvés dans le fichier Json et on se sert de ces objets comme structure de donnée avec une vraie programmation objet proche des articles rédactionnels du gestionnaire en C++.
Pierre

Moi c’est ce que je préférerai pour garder l’acquis et mon expérience.

[DDEFF]

Donc, voici le gestionnaire version 00.
J'ai viré presque tout.

J'ai gardé un menu expurgé pour pouvoir changer le JSON avec de vrais exemples.

La lecture marche toujours, mais ça tourne dans le vide après. Je n'ai pas voulu supprimer des choses que tu avais écrites.
Ne pas s'inquiéter du nombre de fichiers dans "data", seul le fichier JSON sera lu.
Mais ainsi, si on a besoin de modifier aussi l'éditeur, ça marchera

A suivre
Denis

PS : on a passé les 300 000 vues...

[Pierre59]

Je n’arrive pas à faire tourner le programme chez moi.
Le menu ne me propose pas le bon répertoire (un nom de fichier Json en dur serait préférable) et la fenêtre est toujours trop grande (je suis sur  MacBook).

Il faut enlever les traitements du fichier Json provenant de GestJ3 :

Dans void lecture_JSON()   subst(json); ne sert plus.

void initialisationsJson() { …} peut être enlevé !

void zones(String z,Object o) {
void initBrets() {
void fn(String it,String z,Object o) {    peuvent êtres enlevées

void initTables() { // tables de correspondance n° -> nom.    Pourra servir plus tard

// fonctions pour manipuler les tableaux json (taille et indiceage).     peut être enlevé !

// fonctions d'acces et de modification des elements json (cle/valeur).    peut être enlevé !

// fonctions pour substituer certaines valeurs (des entiers a la place de noms)
Jusqu’à la fin de l’onglet, tout peut être enlevé.

Pierre

[DDEFF]

J'ai rectifié la dimension de l'affichage en 1024x720

Je sais pourquoi tu n'arrivais pas à ouvrir le fichier : il était prévu que tu choisisses un fichier .tsv (n'importe lequel) et tu devais choisir le .json, (ce que je comprends).
Une (mal)chance sur 9 
Sauf que .json, ça fait 5 caractères et .tsv, ça n'en fait que 4...
Maintenant, il n'y a plus que les .json et tout marche.

Je tiens à ce que l'on puisse choisir le fichier qu'on veut, pour voir si tous marchent, même maintenant.
Ça complique un tout petit peu au départ, j'en suis conscient.

Il affiche bien tout le json. C'est donc après qu'il subsiste un problème.

Merci pour ton aide.

Denis

[Pierre59]

Après quelques modifications suppressions cela commence à marcher. Mais il y a des différences entre mes appellations et les tiennes: aiguilles/appareils, ...

Le menu ne marche toujours pas sur Mac on est pas dans le bon répertoire.

Pour des tests est que l'on pourrait revenir sur un cas simple le nouveau Locoduinodrome ?

On va pouvoir commencer à instancier les éléments, les zones par exemple et faire un array de zones (voire un arraylist), donc monter un constructeur dans la classe zone.

Pierre

[DDEFF]

OK pour mettre le JSON dans le programme. On le mets comme toi, dans un onglet ?
Et on supprime (momentanément) le menu qui devrait marcher sur Mac (il marchait chez toi pour mes anciens programmes et c'est le même)

Pas d'accord pour le Locoduinodrome. Il me faut un cas réel, avec tous les problèmes (super-appareils, etc...).
On ne teste pas assez de choses sur le Locoduinodrome.

Il faudra, de toutes façons, qu'on ait un JSON sur lequel tout sera commun et qui marche sur tous les réseaux.
Par exemple, on ne pourra pas mettre les itinéraires de Luzy dans le JSON.

Je suis beaucoup plus pour des ArrayList, qui sont beaucoup plus souples en adaptant automatiquement leur longueur.

Denis

[Pierre59]

OK pour mettre le JSON dans le programme. On le mets comme toi, dans un onglet ?

Dans un fichier c'est bien aussi. Je mettais le Json dans un onglet pour pouvoir l'éditer facilement.

Pas d'accord pour le Locoduinodrome. Il me faut un cas réel, avec tous les problèmes (super-appareils, etc...).
On ne teste pas assez de choses sur le Locoduinodrome.

Il faudra, de toutes façons, qu'on ait un JSON sur lequel tout sera commun et qui marche sur tous les réseaux.
Par exemple, on ne pourra pas mettre les itinéraires de Luzy dans le JSON.

Le Locoduinodrome a l'avantage d'être simple et d'être documenté (dessin nom des zones, aiguilles, ...)

Pourquoi utiliser tout de suite des cas beaucoup plus compliqués (on y viendra après) et non documentés.

Je suis beaucoup plus pour des ArrayList, qui sont beaucoup plus souples en adaptant automatiquement leur longueur.

On utilise des Arrays quand on connait la taille ce qui le cas pour les zones, les aiguilles, ... et des arrayslist quand on ne connait pas la taille.

Pierre

[DDEFF]

Bonjour Pierre,

Puisqu'on fait les enveloppes de tous les objets, il faut qu'ils soient tous dans le JSON : zones multiples, super-appareils, ...
Il y a un fichier d'essai qui est beaucoup moins gros que Luzy : c'est le réseau de Dominique avec des ajouts pour qu'on ait tous les cas.
J'aimerais bien qu'on utilise celui-là (Z46 gauche-droite Z51 TJD normale).

De toutes façons, le programme doit être neutre : toutes les infos du réseau sont dans le JSON, rien dans le programme.

A suivre
Denis

[Pierre59]

Puisqu'on fait les enveloppes de tous les objets, il faut qu'ils soient tous dans le JSON : zones multiples, super-appareils, ...

On est dans un gestionnaire, on a besoin de zones, point. Il ne faut pas essayer d'ajouter ce qui te sert dans l'éditeur. Mais avoir juste ce qui est nécessaire au gestionnaire.

Il y a un fichier d'essai qui est beaucoup moins gros que Luzy : c'est le réseau de Dominique avec des ajouts pour qu'on ait tous les cas.
J'aimerais bien qu'on utilise celui-là (Z46 gauche-droite Z51 TJD normale).

Soit, faudrait que tu republie le dessin avec les noms des zones, aiguilles, ...

Pierre

[DDEFF]

Je me suis mal exprimé :
 
il faut qu'on ait dans le gestionnaire tous les objets qui sont dans le JSON.
Soit : params, zones, appareils, bretelles, super_appareils, signaux, balises

Tout ce qui est utile au dessin du TCO n'est pas dans le JSON.

Je remets le JSON correspondant qui était dans le .zip
Les zones multiples sont : Z12, Z15, Z46, Z51

Denis

[Pierre59]

Je me suis mal exprimé :
 
il faut qu'on ait dans le gestionnaire tous les objets qui sont dans le JSON.
Soit : params, zones, appareils, bretelles, super_appareils, signaux, balises

NON, il faut qu'il y ait dans le gestionnaire uniquement les élémentst nécessaires au fonctionnement du gestionnaire. ET seuls ces éléments doivent se trouver dans le Json !

Pierre

[DDEFF]

Je pensais avoir suivi tes consignes et qu'il n'y avait pas dans mon JSON des éléments qui ne servaient pas au gestionnaire.
Vois-tu des éléments "en trop" ou en "pas assez" ?

Denis

[Pierre59]

Pour l'instant dans le fichier json je vois des "super appareils" et des "bretelles". Il faudra certainement quelque chose pour les bretelles mais pas forcement comme cela, pour les super appareils je ne vois pas ce que c'est.

Pierre