Projet partagé d'un gestionnaire de réseau

[DDEFF]

Mais on peut faire les deux, justement.
Je comprends mieux quand on applique à un cas concret.

On aura besoin d'objets, de leurs liens et d'explications au fur et à mesure. Je ne veux pas me presser.

Tu as démarré par les signaux et je pense que c'est une bonne piste.

1°) De quels objets on a besoin pour les signaux ?
2°) Quels lien y-a-t' il entre eux ?
3°) Comment rentrer les infos du JSON dans ces objets ?
Et peut être d'autres choses ...

Denis

[Pierre59]

1°) De quels objets on a besoin pour les signaux ?
=> on a surtout besoins d'accès aux signaux voisins !
2°) Quels lien y-a-t' il entre eux ? ces relations de voisinage
3°) Comment rentrer les infos du JSON dans ces objets ?
=>Processing a tout ce qu'il faut pour traiter les fichiers Json, Le gestionnaire, en Processing, basé sur un fichier Json que j'ai publié montre bien tout cela, de toute façon je t'aiderais.
Et peut être d'autres choses ...

Pierre

[DDEFF]

Signal voisin d'un signal : ça dépend des itinéraires.

Un signal est dans une zone. On a les voisins de la zone en fonction des positions des appareils de voie dans le JSON.
Donc, on peut calculer le signal voisin.
On pourrait le faire dans le signal du JSON ou alors dans le setup du gestionnaire.
C'est facile à ajouter dans le JSON, mais je pense que ça sera redondant. Je trouve que ça serait mieux dans le setup.

JSON : est-ce qu'on travaille directement dans le fichier ou est-ce qu'on extrait les infos dans des objets et on travaille dans les objets ?

Denis

[Pierre59]

Un signal est dans une zone. On a les voisins de la zone en fonction des positions des appareils de voie dans le JSON.
Donc, on peut calculer le signal voisin.
On pourrait le faire dans le signal du JSON ou alors dans le setup du gestionnaire.
C'est facile à ajouter dans le JSON, mais je pense que ça sera redondant. Je trouve que ça serait mieux dans le setup.

==> le signal précédent et/ou le signal suivant peuvent dépendre de la positions d'aiguilles, donc cela ne peut être fait dans le setup() !!!  mais dans la classe SIGNAL.

JSON : est-ce qu'on travaille directement dans le fichier ou est-ce qu'on extrait les infos dans des objets et on travaille dans les objets ?

==> Il me semble que le traitement directement dans le fichier Json n'avait pas fait l'unanimité, on peut essayer de créer  les objets à partir du fichier Json !


Pierre

[DDEFF]

Bonjour,

Merci pour ces précisions.

Quand je disais "dans le setup", c'était sous forme de liste, du même type que les voisins de zones dans le JSON, en tenant compte, justement, de la position des appareils de voie.
Mais je me rends compte que ça ne ferait pas avancer le problème.
C'est effectivement dans la classe Signal que ce sera au meilleur endroit.

J'avais bien vu dans ton programme que la lecture du JSON était très courte (quelques lignes) et je n'avais pas saisi.

Dans Processing, si j'ai bien compris, il y a deux fonctions qui lisent (ou écrivent) soit un objet {...}, soit une ArrayList [..., ...].

Mais vu le mélange complexe d'accolades et de crochets qu'il y a dans un JSON, je ne m'y retrouvais pas et c'est pour ça que je n'ai pas utilisé les fonctions d'écriture dans la construction du JSON dans l'éditeur.
J'ai donc fait tout le travail "à la petite cuillère", ce qui est très compliqué, très long et pas satisfaisant du tout.

Donc, oui, je préfèrerais qu'on mette les infos du JSON dans des objets avant de les utiliser.

On garderait la lisibilité du JSON par un humain (par rapport à une table), mais on perdrait la logique interne du JSON qui, justement, permet de "travailler dedans".
Je ne dis pas que j'en viendrai à "travailler dedans", plus tard, quand j'aurais bien intégré toutes les subtilités du JSON.

Merci pour ton aide

Denis

[Pierre59]

Pour ce qui est de la conversion Json ==> objets (zones, signaux,aiguilles, …), l'onglet Json (au début) du programme GesJ3 est un bon exemple des traitements possibles.

Pierre

[DDEFF]

C'est bien la partie que j'avais lue.
Mais tu as une notation très compacte, avec des variables à une seule lettre qui sont très efficaces, je le reconnais, mais un peu dures à lire.
Et je pense que tu es plus dans du Java que dans du Processing (tu fais appel à Java dès le début) et c'est parfois déroutant pour moi.

Ex :

Code: [Sélectionner]

  for (String z : (Set<String>)zones.keys()) { String s; // pour toutes les zones     
    etatZone(z,LIBRE); // etat libre
    trainZone(z,null);   // pas de train
    verrZone(z,null); // pas de verrou (null) (sinon "nom" d'itineraire pour zones)
   
    if ((s=signIZone(z))!=null) zoneSign(s,z); // a voir (utilite)
    if ((s=signPZone(z))!=null) zoneSign(s,z);// zone du signal dans signal
  }

Je ne comprends pas la syntaxe de la première ligne : De quelles "keys" parle-t-on ?
La dernière ligne avec un "=" et un "!=" presque dans la même parenthèse m'est incompréhensible...

J'utilise beaucoup de void XX () {} et très peu de int XX () { return ...}, String XX () {return...}, tout l'inverse de toi.
Comme disent les jeunes, il y a un "gap" entre nous au niveau programmation...

Denis

[Pierre59]

L'URL suivante donne toutes les informations sur Json:

https://processing.github.io/processing-javadocs/core/

Il faut que tu ailles voir, on en discutera après.

Notamment on trouve toutes les méthodes applicables à JsonObject et JsonArray, c'est au format javadoc.

On y trouve par exemple la méthode Keys dans JsonObject.

Pierre

[DDEFF]

Merci, c'est parfait. Ce sera très utile.

Analyse de l'onglet json :

On crée un objet "json" qui est tout ce qui est entre les accolades principales
On crée des objets contenus dans le JSON (zones, signaux, …)
On lit tout le JSON d'un seul coup avec lectureJson(String f);
La syntaxe "lectureJson(no==1?"Z1.pde":"Z2.pde");" veut certainement dire si no==1, on lit Z1.pde, sinon on lit Z2.pde.
Après, on lit tous les "grands" objets du JSON (zones, aigs, …) avec getJSONObject
Subst(json); sert à traduire les textes clairs pour les humains en nombres plus compacts et faits pour le programme.
Suit l'initialisation des clés de chaque objet : etatZone(), trainZone(), verrZone()
Une variable String s est déclarée et on va chercher dans le JSON, le signal côté impair qui va aller remplir s. Et si s n'est pas null, on fait ZoneSign(s,z);, ce qui nous donne la zone du signal correspondant. Sauf que dans le signal du JSON, il n'y a pas de zone du signal...

Denis

[DDEFF]

J'ai compris !

La zone, elle, a le nom du signal et s, c'est le signal.

Denis

[Pierre59]

Voila l'onglet Json expurgé, on extrait d'une zone ses deux signaux. Avec beaucoup d'explications.

Perre

[Pierre59]

J'ai compris !

La zone, elle, a le nom du signal et s, c'est le signal.

==> la zone elle son nom : Z1, Z12, … et le signal son nom : C3, Cv1, … les noms qui sont dans le json !

Pierre

[DDEFF]

C'est assez étrange : dans ton programme, il n'y a pas de "Class" ...
En fait, la description des objets se fait dans l'onglet JSON, JSONObject.

Je vais essayer de lire le JSON, en l'écrivant un peu plus à ma

[Pierre59]

C'est assez étrange : dans ton programme, il n'y a pas de "Class" ...

==> en fait je cherche tous les paramètres d'une zone à partir du Json, pour pouvoir faire un new Zone(...), donc une instance de la classe Zone, qui faudra mettre quelque part (la class et l'instance).

En fait, la description des objets se fait dans l'onglet JSON, JSONObject.

[DDEFF]

Je vais essayer de lire le JSON, en mettant ton programme un peu "à ma sauce", mais en gardant les écritures sur une ligne quand je les comprends.
C'est plus compliqué quand tu fais sauter des accolades (dans les if, j'ai un peu de mal). Mais c'est assez clair.

Je récupérerai aussi le TCO sous forme de tables (j'aurais pu faire une seule table, mais pleine de vides) car je n'utiliserai pas de tube ni de messages.

On va voir ce que ça donne, ça sera déjà pas mal.

J'ai remarqué une subtilité dans le JSON pour les voisins des zones :
Tu les vois comme une arrayList de plusieurs ArrayList alors que moi, je le voyais comme un objet d'ArrayList. C'est hyper simple à corriger dans l'éditeur_JSON.
Il faudra me laisser un peu de temps.

A suivre
Denis