Discussion :

[clairetj]

Bonjour à toutes et à tous,

Ce que je vais présenter ici risque de vous paraitre assez obscur (dans la formulation) car je n'arriverais sans doute pas expliquer correctement ce que je veux faire, je vous pris donc de bien vouloir m'en excuser.

Actuellement, j'ai développé un programme en C++ sous Qt (avec une IHM) pour établir une communication série entre mon PC et un automate. Ce programme me permet aussi de pouvoir allumer ou éteindre des LEDs se trouvant sur les sorties TOR de l'automate lorsque j'appuie sur des boutons sur l'IHM. Le programme marche pour l'instant.

Maintenant, je voudrais déporté mon IHM Qt sur une page web et pouvoir interagir depuis ma page web sur mon automate. En gros, je veux faire exactement comme si j'utilisais l'IHM développé sous Qt mais sur un navigateur web. Je suppose donc qu'il va falloir opter sur une architecture client/serveur et donc rajouter une fonction serveur à mon programme.

J'ai déjà essayer plusieurs solutions mais sans succès (en témoigne de nombreux topics que j'ai ouvert) et si je me souviens bien, il a émis une fois l'utilisation de BDD (base de données).
Si je me souviens bien, l'idée serait:
1-La page web envoit l'ordre que je veux effectuer dans la base de donnée
2-L'ordre est stocké dans la base de donnée
3-Le serveur interroge la base de donnée pour voir s'il y a un ordre de stocké
4-Le serveur trouve l'ordre dans la base de donnée et l'exécute.

Je fais appel à mes souvenirs donc j'ai quand même un doute sur la véracité de cette technique mais si elle est possible, pouvez-vous me renseigner sur de la documentation/tutoriels qui pourrais m'aider ?

Cordialement,
Clairetj

[imperio]

Ce que tu pourrais faire c'est juste un serveur qui execute l'ordre donne. Si tu utilises le protocole html il te suffira de parser la requete pour savoir quelle ordre executer (il me semble que Qt a une classe pour ca). Je vois pas vraiment pourquoi tu voudrais utiliser une bdd par-contre. Tu veux sauvegarder les commandes executees ?

[clairetj]

Je ne pense pas que sauvegarder le commander me soit vraiment utile

Par contre est-ce que tu pourrais détailler un peu plus ton idée quand tu dit

Si tu utilises le protocole html il te suffira de parser la requete pour savoir quelle ordre executer (il me semble que Qt a une classe pour ca)

parce ue j'ai essayer une multitude de chose sans que cela marche.

Quelle est la classe Qt qui ferai cela ?

[white_tentacle]

Je ne sais pas qui t’a conseillé de passer par une base de données, mais ça me semble une mauvaise idée : compliqué à mettre en œuvre, pas fiable, nécessité de faire un polling actif… Personnellement, je déconseille fortement cette solution.

D’autant que… comme tu as probablement bien architecturé ton projet (et si ce n’est pas le cas, il n’est pas trop tard pour le corriger) ta couche de présentation est logiquement indépendante de tout ton code métier (celui qui communique avec l’automate).

Donc je te propose plutôt de changer uniquement ta couche de présentation, par une autre. Deux solutions :
- soit tu fournis un web-service ou assimilé (json-rpc), et une interface purement javascript/html5
- soit tu fournis une application web, réalisée par exemple avec la librairie webtoolkit (attention, elle est payante si la GPL n’est pas adaptée).

[clairetj]

D’autant que… comme tu as probablement bien architecturé ton projet (et si ce n’est pas le cas, il n’est pas trop tard pour le corriger) ta couche de présentation est logiquement indépendante de tout ton code métier (celui qui communique avec l’automate).

Bon déjà, on va dire que qu'à la base, je reprend le projet de mon prédécésseur et on va dire que le code qu'il m'a laisser pour la communication avec l'automate est un peu fouillis mais j'arrive encore à m'en sortir. Sauf que je suis allé tellement de fois dans le mur que je repart sur ma base de départ que je pose ici.
Actuellement, j'ai:
-mainwindow.ui qui est mon IHM pour faire la communication entre mon PC et l'automate (et allumer/éteindre des LEDs)
mainwindow.ccp et mainwindow.h qui sont les deux fichiers de mon programme de communication entre mon PC et mon automate.
-main.cpp ba c'est mon main qui me lance mon programme

Donc je te propose plutôt de changer uniquement ta couche de présentation, par une autre. Deux solutions :
- soit tu fournis un web-service ou assimilé (json-rpc), et une interface purement javascript/html5
- soit tu fournis une application web, réalisée par exemple avec la librairie webtoolkit (attention, elle est payante si la GPL n’est pas adaptée).

Je pense prendre la première solution donc dit moi moi si je me trompe.
Dans mon programme actuel, il faut que je rajoute (par exemple) un fichier serveur.cpp et serveur.h créant une classe pour faire mon serveur. Et ensuite je crée une interface web en html (je ne connais pas le javascript donc j'opterai pour le html). Est-ce que ma démarche semble logique ?

Par contre, en faisant des recherches, j'ai lu que je risque fortement d'utiliser le protocole HTTP; or je ne le connait pas donc est-ce que quelqu'un aurait une documentation/tutoriel à me conseiller ?

[therwald]

en html (je ne connais pas le javascript donc j'opterai pour le html)

Globalement c'est l'idée, mais concernant HTML...en HTML, surtout en HTML5, HTLM ne sert qu'à spécifier la partie "visuelle" de l'interface, le comportement, lui, est décrit en...javascript
Allez, des appels de servcie en js ce n'est pas la mort, rassure-toi, même moi qui suis loin d'être un fan de javascript je le dis

[clairetj]

Globalement c'est l'idée, mais concernant HTML...en HTML, surtout en HTML5, HTLM ne sert qu'à spécifier la partie "visuelle" de l'interface, le comportement, lui, est décrit en...javascript
Allez, des appels de servcie en js ce n'est pas la mort, rassure-toi, même moi qui suis loin d'être un fan de javascript je le dis

On va dire que le problème ne repose pas sur le fait que je ne sois pas fan du javascript, c'est surtout que je le n'ai jamais vu donc je ne sais pas quoi chercher, et hélas je ne pense pas avoir le temps d'apprendre le java script, vu que c'est un projet pour mon entreprise (je suis un alternant) et que cela commence à urgé.

Par contre, on est bien d'accord sur le fait qu'il faut que je rajoute un fichier (par exemple) serveur.cpp et serveur.h à mon projet pour créer une classe serveur qui servira à la création/gestion de mon serveur (je pense avoir trouver le code à implémenter, même s'il faudra des modifications).

En revanche et là où je suis totalement bloqué, c'est sur:
1- Comment récupérer les ordres en provenance de ma page web (je suppose que cela aura à avoir avec le javascript)
2- Comment dire à mon programme de communication (mon mainwindow.cpp) d'exécuter l'ordre reçu par mon serveur

[therwald]

En gros, un serveur web rpc (effectivement mis en place par ta classe server (et plus si affinités, n'oublie pas que limité le travail fait par une classe donnée et répartir le travail est un excellent remède conrte la migraine ) ) met en place une URL capable de recevoir une requête POST, qui est traduite en un appel de fonction avec divers arguments.
L'argument principal est le contenu json, qui est la description sérialisée d'un objet. Là tu as ton objet équivalent en c++ qui reçoit les données (soit l'identification de ta commande et les éventuels paramètres) et représente la commande reçue. Avec cette commande, tu appelles ta fonction de contrôle qui communique avec l'automate (cette fonction est celle que ton interface Qt appelle si tu as bien fait une séparation interface / coeur applicatif correcte.

Côté javascript c'est assez simple: tu définis une fonction onclick pour ton bouton "envoyer" (ou équivalent). Dans cette fonction onclick, tu crées un objet javascript qui a les mêmes données que ton objet c++ de commande. Ensuite, tu poste ton objet javascript sur ton URL de serveur (la sérialisation json est native en javascript).
Pour l'apprentissage accéléré de JS, tu peux regarder là, moi je m'y réfère souvent, ça fait un point de départ assez correct quand on commence de 0.

[therwald]

PS: si tu veux vraiement du pur HTML côté interface, tu peux faire un serveur web pur jus appelé par des formulaires, mais je ne suis pas persuadé que le parsing de paramètres de requête soit spécialement plus simple si tu ne connais pas...

[clairetj]

Je sais que je vais abusé un peu en disant cela mais si je prend un exemple tiré de mon programme: dans mon mainwindow.cpp le slot qui me permet d'allumer la LED1 lorsque j'appuis sur le bouton de IHM correspondant est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void MainWindow::on_pushButton_LED1_clicked()
{
    sortieTOR[0] = !sortieTOR[0];
    if(sortieTOR[0]==1)
    {
        ui->label_LED1->setText("LED1 allumée");
    }
    else
    {
        ui->label_LED1->setText("LED1 éteinte");
    }
}

Dans ma page web par exemple, j'ai:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<form action="" method="POST">
		<input type="submit" style="width:200px" name="LED1" value="LED1">
</form>

il faut donc si je comprend bien que je rajoute dans cette parti du javascript qui crée un objet javascript qui a les mêmes données que ton objet c++ de commande (je suppose le nom de mon slot donc dans l'exemple que j'ai donné on_pushButton_LED1_clicked()). Ensuite, je poste mon objet javascript sur l'URL de serveur si je comprend bien toujours.

Par contre cette partie-là

En gros, un serveur web rpc (effectivement mis en place par ta classe server (et plus si affinités, n'oublie pas que limité le travail fait par une classe donnée et répartir le travail est un excellent remède conrte la migraine ) ) met en place une URL capable de recevoir une requête POST, qui est traduite en un appel de fonction avec divers arguments

je ne l'a comprend pas

[white_tentacle]

MainWindow c’est ta classe d’interface graphique. S’il y a dedans toute la partie communication avec l’automate, c’est… très mal .

Première chose à faire : refactoriser le code et sortir toute la communication avec l’automate dans une classe qui ne se chargera que de ça. Et l’interface graphique, elle, s’occupera de faire les appels à cette classe et d’y récupérer les informations.

Globalement, tu dois arriver à une situation où :
- la partie communication n’a aucune connaissance de la partie interface
- la partie interface, en revanche, utilise la partie communication, mais seulement sous la forme d’appels très simples (genre clic sur ce bouton -> exécuter telle méthode). Pas de traitements complexes dedans, c’est le principal.

Une fois que cette étape sera faite (et elle n’est pas triviale suivant le degré d’imbrication qu’a fait le le programmeur précédent), tu auras quelque part défini une interface au niveau de ta partie communication, qu’utilise ton interface Qt. Tu vas pouvoirs assez facilement remplacer cette interface par un serveur web (json-rpc ou soap), qui, recevra les commandes via json-rpc. Tu peux par exemple utiliser cette bibliothèque https://bitbucket.org/devonit/qjsonrpc pour faire le service.

Te restera à faire la partie client, mais là, ce sera du web, plus rien à voir avec le C++ .

[clairetj]

J'ai quasiment réussi à séparer ma partie communication série de la partie IHM Qt (il me reste encore deux trois bricoles mais je suis sur le coup).

Par contre pour la suite, je dois avouer que je suis un peu larguer: actuellement, le seul code de serveur que j'ai pu croisé sous Qt était un code pour un serveur TCP (et je suppose qu'un serveur HTTP est complétement différent d'un serveur TCP). Et je ne connais pas du tout se dont tu me parle, à savoir "serveur web (json-rpc ou soap)"

Est-ce que tu pourrais m'en dire plus (on va dire que je suis un peu une buse en réseau) ?

[white_tentacle]

Pour l’instant, je ne vois pas trop ce qui est séparé… vu qu’il n’y a qu’un seul fichier

Dans l’idée, tu vas d’abord créer une nouvelle classe (qui dérive de QObject pour pouvoir exporter tes signaux et tes slots). C’est celle-ci, et uniquement celle-ci, qui va s’occuper de gérer la communication RS.

Pour l’instant, de ce que je vois, la lecture est lancée par un timer toutes les X secondes. C’est pas la bonne façon de faire, mais tu peux garder ça pour l’instant, ça marche. C’est cette partie là que tu vas devoir déplacer dans ta nouvelle classe.

Ensuite, toujours dans cette nouvelle classe, tu vas définir un certain nombre de signaux : ces signaux voft notifier des changements d’état. De ce que j’en vois, pour l’instant, la réception des données ne fait qu’écrire dans un fichier. À mon avis, ça fait partie des choses que tu dois améliorer.

Enfin, toujours dans cette nouvelle classe, tu vas définir un certain nombre de slots, correspondant aux opérations que tu dois effectuer sur la ligne de communication (celles qui sont actionnées à la demande). Cela va être, par exemple la méthode sendTrameWriteModBus qui me semble un bon candidat.

Une fois que cette partie sera faite, il te faudra « connecter » l’interface à ta nouvelle classe, c’est à dire :
- appeler les bons slots avec les bons paramètres en fonction des actions utilisateurs
- réagir aux différents signaux pour mettre à jour l’interface en fonction


Enfin, une dernière chose : le code que tu récupères est une horreur (comme on en voit trop souvent, hélas) en terme de conception (en fait, il n’a pas fait l’objet de conception tout court). De ce côté là, tu n’as pas de chance, mais tu peux améliorer, petit à petit, les choses.

edit : arf, tu as édité ta réponse en même temps que je répondais. Content que tu commences à en voir le bout

[clairetj]

Voici les dernières versions en réorganisant

automate.h : http://pastebin.com/HiE6AHfS

automate.cpp : http://pastebin.com/4RW70eST

mainwindow.h : http://pastebin.com/gC2ZQJiP

mainwindow.cpp : http://pastebin.com/tZ76afQJ

J'ai encore deux slots dans mon automate.cpp qui font intervenir l'IHM mais je suis sur le coup, j'essaie de régler le problème mais dit moi ce que tu en pense (PS: dans le mainwindow.h, je me doute que je pourrais nettoyer mieux mes include, mais pour l'instant dans le doute, j'ai préféré les garder tel quel).

[white_tentacle]

Pour jsonrpc, regarde le lien que j’ai donné : dans la partie « tests », il y a des exemples de client et de serveur. Toi, c’est uniquement le serveur qui va t’intéresser.

Pour cette partie, pas besoin de grandes notions réseau (même si ça peut toujours être utile). Normalement, si ta classe communication est bien définie, le service sera ultra-simple : il ne fait que fournir une passerelle vers cette classe : les méthodes seront donc les mêmes, les signaux aussi.

Pour la partie client, ce sera un peu différent, là il faudra mettre les mains dans le html/js (pas le choix).

[clairetj]

et je risque de passer pour un boulet (comme d'hab quoi ) mais dans le lien que tu m'as donné pour jsonrpc (https://bitbucket.org/devonit/qjsonrpc si je ne me trompe pas), je ne trouve pas la partie test en question

[white_tentacle]

J'ai encore deux slots dans mon automate.cpp qui font intervenir l'IHM mais je suis sur le coup, j'essaie de régler le problème mais dit moi ce que tu en pense (PS: dans le mainwindow.h, je me doute que je pourrais nettoyer mieux mes include, mais pour l'instant dans le doute, j'ai préféré les garder tel quel).

Là, tu as déplacé les choses, mais en aucun cas tu ne les as rendues indépendantes ! J’en veux pour preuve la présence d’un ui::MainWindow dans ta classe Automate.

Ta classe Automate n’a pas le droit d’avoir la moindre connaissance du moindre élément de ton interface.

Si elle doit, pour une raison une autre, faire une mise à jour de l’interface, il y a deux possibilités :
- c’est bien elle qui est à l’origine de l’évènement qui nécessite la mise à jour (par exemple, réception de données suite à une requête modbus), alors elle émet un signal
- ce n’est pas elle qui est à l’origine de l’évènement, alors probablement ce petit bout de code n’est pas au bon endroit.

[white_tentacle]

et je risque de passer pour un boulet (comme d'hab quoi ) mais dans le lien que tu m'as donné pour jsonrpc (https://bitbucket.org/devonit/qjsonrpc si je ne me trompe pas), je ne trouve pas la partie test en question

Dans le source.

[Davidbrcz]

Sinon tu peux faire du web a partir du C++. J'ai pas souvent vu de cas ou c’était justifié, mais la je pense que ca l'est

http://cppcms.com/wikipp/en/page/main

[clairetj]

Là, tu as déplacé les choses, mais en aucun cas tu ne les as rendues indépendantes ! J’en veux pour preuve la présence d’un ui::MainWindow dans ta classe Automate.

Ta classe Automate n’a pas le droit d’avoir la moindre connaissance du moindre élément de ton interface.

Si elle doit, pour une raison une autre, faire une mise à jour de l’interface, il y a deux possibilités :
- c’est bien elle qui est à l’origine de l’évènement qui nécessite la mise à jour (par exemple, réception de données suite à une requête modbus), alors elle émet un signal
- ce n’est pas elle qui est à l’origine de l’évènement, alors probablement ce petit bout de code n’est pas au bon endroit.

Je suis en train de le corriger, tout n'est pas encore au point mais je m'y atèle du mieux que je peux actuellement