Recherche piste de réflexion/tutoriel pour communication entre un programme en c++ avec BDD

Citation:

---

Envoyé par white_tentacle

@bousk : ça veut quand même dire parser toute la command line côté c++, et côté python parser tout le retour. Ça se fait, mais je maintiens que ça rajoute encore des choses avec lesquelles l’op ne sera pas forcément à l’aise, et que ce sera l’enfer si tu veux pouvoir gérer des évènements initiés par l’équipement / le programme et pas par l’interface (tu vas devoir faire du polling actif…).

---

Le problème initial consiste à "j'appuye sur un bouton, ça allume/éteint"
Il ne s'agit pas d'un super ordinateur de bord temps réel web
Le code retour du programme, on peut s'en moquer, pour avoir l'info à jour, utiliser les spécificités du web : on affiche une page statique, on gère le côté dynamique via du javascript etc pour rafraichir le contenu
Si l'application fait une action toute seul (chose non abordée jusqu'ici, donc pure supposition ?), le client affichera le contenu à jour au refresh qui suit

A fortiori, l'op est un développeur web à la base, là il s'agira de faire strictement du web, le côté serveur se fait en qqs heures, puis on fignole l'interface web; et il s'agira de purs upgrade de l'appli principal quand nécessaire, sans même avoir besoin de toucher au serveur si l'on crée les bonnes méthodes/opérations

Citation:

---

Envoyé par clairetj

Vu que pour chaque ports, on crée un lien entre le port et une action dans le menu, on récupère l'action et on l'affiche dans le menu. Sauf qu'à priori il aime pas. Pourquoi ?

---

Le type est incomplet vu que tu n'as que la forward declaration. Dans ton impleme tu vas avoir besoin de l'import du header.
Mais dans un .cpp l'effet est plus localisé que dans un header.
Autre possibilité, plus longue mais plus propre, tu fais une classe d'adaptateur autour de ta référence d'interface, de manière à ce que ton core soit réellement indépendant du type de l'interface.
C'est ta classe d'adaptateur, abstraite, qui a la référence de l'interface, et elle a une implémentation pour la window, et une pour le serveur web. Elle définit la fonction membre virtuelle registerPort(), qui fait ce qu'elle a à faire pour enregistrer ton port dans l'interface.
Et c'est la main qui instancie le bon adaptateur puisque c'est elle qui instancie l'interface donc sait de quel type d'interface il s'agit

Citation:

---

Envoyé par Bousk

A fortiori, l'op est un développeur web à la base, là il s'agira de faire strictement du web, le côté serveur se fait en qqs heures, puis on fignole l'interface web;

---

J'avais pas compris ça pour ma part, puisqu'il avoue être une quiche intégrale en js et pas trop le temps ed s'y mettre...

Citation:

---

Envoyé par therwald

Le type est incomplet vu que tu n'as que la forward declaration. Dans ton impleme tu vas avoir besoin de l'import du header.

---

Au risque de passé pour une bille, je suppose que faire un include monfichier.h ne suffit pas

Quand tu fais une forward declaration, tu dis juste au compilateur: "hey, la classe XXX existe".
Ca suffit pour définir un pointeur ou une référence sur cette classe, mais il n'y a pas les info pour appeler des fonctions membres de la classe (pour ça il faut inclure le header).
Dans dans ton *.cpp il faut inclure le header de ta classe d'interface pour pouvoir en appeler les méthodes.
Ou alors tu avance un peu dans la conception et tu définis un adaptateur, qui lui a des fonctions à appeler par automate pour faire des choses comme enregistrer l'existence d'un port série. La signature de ces fonctions doit être conçues pour masquer la nature de l'interface (dans ce cas c'est l'adaptateur qui crée la QAction, à partir des données neutres dont dispose le core (nom de port, par ex?)

Citation:

---

Envoyé par therwald

Quand tu fais une forward declaration, tu dis juste au compilateur: "hey, la classe XXX existe".
Ca suffit pour définir un pointeur ou une référence sur cette classe, mais il n'y a pas les info pour appeler des fonctions membres de la classe (pour ça il faut inclure le header).
Dans dans ton *.cpp il faut inclure le header de ta classe d'interface pour pouvoir en appeler les méthodes.

---

Donc, en haut de mon fichier.cpp je fais #include "mainwindow.h" (ça m'embête de le remettre la vu que le l'avais déjà mis dans mon automate.h donc je ne vois pas l'utilité de le remettre)

edit: oops, pas vu la page suivante

Dans automate.h, tu n’inclus pas mainwindow.h. Tu déclares simplement :

Code:

---

1 2	class MainWindow;

---

.

Idem dans mainwindow.h : tu n’inclus pas automate.h, tu déclares seulement :

Code:

---

1 2	class Automate;

---

dans mainwindow.cpp : tu inclus mainwindow.h et automate.h
dans automate.cpp : tu inclus automate.h et mainwindow.h

(l’ordre n’est pas spécialement important à ce niveau).

La FAQ explique ça normalement ;).

http://cpp.developpez.com/faq/cpp/?p...TES_ou_inclure

dans mon automate. j'ai défini m_interface comme ceci:

Code:

---

1 2	private: MainWindow *m_interface;

---

mon setInterface est comme ceci:

Code:

---

1 2 3 4

void Automate::setInterface(MainWindow* interface) { this->m_interface = interface; }

---

et voici mon main

Code:

---

1 2 3 4 5 6 7 8 9 10

int main(int argc, char *argv[]) { QApplication a(argc, argv); Automate automate; MainWindow window(&automate); automate.setInterface(&window); window.show();   return a.exec(); }

---

Le main me semble bon, j’ai édité ma réponse.

Citation:

---

Envoyé par clairetj

Donc, en haut de mon fichier.cpp je fais #include "mainwindow.h" (ça m'embête de le remettre la vu que le l'avais déjà mis dans mon automate.h donc je ne vois pas l'utilité de le remettre)

---

Ce n'est pas la même chose de mettre l'include mainwindow dans le header ou le CPP.
Dans le premier cas, toute classe utilisant ta classe automate sera recompilée quand on change mainwindow, dans le second, seul automate doit être recompilé.
L'idéal en conception serait d'utiliser l'adaptateur dont je t'ai parlé afin que la classe automate cesse d'être liée à mainwindow.

Je viens de me rendre compte de quelque chose:

Dans mon main, on crée en premier un automate, puis on crée une mainwindow qui va connaitre l'existence de l'automate créée

Or dans mon constructeur de mon automate, dedans, je lance la méthode detectionPortCOM. Cette méthode à besoin d'avoir connaissance de mainwindow.
Or vu que je crée d'abord l'automate (et donc avec le constructeur, le lance la méthode detectionPortCOm), la mainwindow n'étant pas encore créée, cela doit faire un conflit

le problème ne viendrait-il pas de là ???

Je confirme que c’est un problème !

Dans ton cas, tu peux corriger assez simplement ton problème en déplaçant cette partie du code dans une méthode « init », que tu appelleras après le setInterface…

Pour éviter de multiplier les appel post construction, peut-être que ce devrait être init qui prend l'interface en paramètre.

Le problème venait bien de là, j'ai fait mes modifications et j'arrive (enfin ) à avoir à nouveau mon interface qui apparait.
La détection des ports COM et leur affichage dans l'interface se fait bien et j'arrive à sélectionner sur quel port je veux établir ma communication (comme avant).

Mais bon, vu que j'ai pas de chance, nouveau problème: je n'arrive plus à me connecter à mon automate :cry:

Je vais donc essayer de voir d'où sa vient et si je ne trouve pas je reviens faire un saut ici.
En tout cas merci pour votre aide pour cette étape de restructuration de code

Finalement, c'est bon j'ai retrouvé ma connexion à mon automate et cela marche comme mon programme originel très très mal organisé:ccool:


Je suis donc prêt à passer à la suite, à savoir: le serveur

Du coup première question: sachant que mon client sera une page web, me faut-il un serveur TCP ou un serveur HTTP ???

Un serveur HTTP serait l'idéal, comme ça tes formulaires seront automatiquement traités, tu n'auras plus qu'à "câbler" la récupération des valeurs. (en TCP ça fonctionnerait pareil...sauf que tu aurais le parsing HTTP à te tapper à la mano :aie:)

du coup, comme j'avais un peu fait des recherches sur "comment programmer sous Qt un serveur HTTP" je suis tombé sur ça:
http://doc.qt.digia.com/solutions/4/...le-server.html

la façon dont c'est écris me gêne un peu. J'ai l'impression (c'est à quoi je pense quand je lis le code) que c'est un simple fichier.h dans lequel on aurait mis le code qui "normalement" ce trouverait dans un fichier.cpp (mais je peux me trompé, c'est comme ça que je comprends le code)

Ensuite (et même si je pense que je vais devoir faire des modification), est-ce que ce genre de code peut convenir pour réaliser mon serveur HTTP ?

alors, votre avis sur le code de mon précédent post ???

L'exemple de code de ton lien ne montre...qu'un serveur TCP qui se trouve renvoyer un fichier HTML en cas de requete.

Citation:

---

Envoyé par therwald

L'exemple de code de ton lien ne montre...qu'un serveur TCP qui se trouve renvoyer un fichier HTML en cas de requete.

---

Ok donc c'est pas ce que je recherche, je vais continuer à chercher.
Et pour en revenir au fait d'avoir séparer la partie interface de la partie automate, en gros en ayant fait cela je pourrait remplacer dans le futur la partie interface par la partie serveur: "Je crée un automate, je crée un serveur qui a connaissance de l'automate, etc ..." c'est ça ???

Citation:

---

Envoyé par clairetj

Ok donc c'est pas ce que je recherche, je vais continuer à chercher.
Et pour en revenir au fait d'avoir séparer la partie interface de la partie automate, en gros en ayant fait cela je pourrait remplacer dans le futur la partie interface par la partie serveur: "Je crée un automate, je crée un serveur qui a connaissance de l'automate, etc ..." c'est ça ???

---

C’est exactement ça. Comme tu as séparé les deux (dans la réalité, ce n’est pas encore tout à fait terminé, il va falloir que tu finisses complètement le travail en ne créant pas les actions et les menus dans l’automate, mais en renvoyant à l’interface les informations suffisantes pour que elle crée les actions et les menus).

Sinon, je ne comprends pas pourquoi la solution json-rpc ne te plaît pas. Ni la solution cppcms, d’ailleurs. Les deux me semblent les plus simples, tu ne vas certainement pas réimplémenter une couche HTTP, ni même un protocole applicatif par dessus HTTP.

Citation:

---

Envoyé par white_tentacle

Sinon, je ne comprends pas pourquoi la solution json-rpc ne te plaît pas. Ni la solution cppcms, d’ailleurs. Les deux me semblent les plus simples, tu ne vas certainement pas réimplémenter une couche HTTP, ni même un protocole applicatif par dessus HTTP.

---

C'est pas que les solutions que tu me propose ne me plaisent pas, c'est que je ne l'ai comprend pas, je galère vraiment (pour le serveur tu me parle bien de ça: https://bitbucket.org/devonit/qjsonr....cpp?at=master)

Je suis en train de parcourir le net pour trouver des réponses à mes interrogations et je voudrais en soulever une ici:
Je croise beaucoup lors de mes recherches les mots "scripts CGI" alors j'ai regardé ce que c'est et de ce que j'ai compris, un script CGI est un programme pouvant être exécuté par le serveur HTTP si ce dernier reçoit une requête de type GET ou POST.

Actuellement, pour développer la partie web j'ai notepad++ et wampserver (oui je suis sous windows). Or wampserver possède déjà un serveur HTTP: Apache.
Par la suite, mon programme sera mis sur une Raspberry Pi qui possèdera elle aussi un serveur HTTP embarqué: lighttpd.

Donc ma question est: est-ce vraiment nécessaire pour moi de rajouter dans mon programme un serveur HTTP ??? Et est-ce que l'utilisation de scripts CGI vous parait adapter à mon utilisation ???

Il me semble qu'un post précédent a mentionné une classe utilitaire Qt qui implémente le protocole HTTP. Si tu maîtrises bien Qt, ET SI tu trouves cette classe (ou si quelqu'un te la pointe, pour ma part je ne connais pas Qt), ça peut être une solution.
Logiquement il ne devrait y avoir aucun difficulté.
Globalement, le serveur doit te permettre d'exposer une série d'URL du style <URL de base du serveur>/allumerLED, chacune correspondant à une commande possible. Pour les commande qui prennent des paramètres, les valeurs des champs de formulaire correspondants sont automatiquement passés par le navigateur en tant que paramètres de la requête, et une bonne API de serveur HTTP doit te permettre de les récupérer sous forme de paries clef-valeur (soit en tant que chaîne de caractères à transcoder, soit pour un framework complet, avec transcodage automatique pour arriver dans le bon type).
Personnellement, je ne connais le développement Web que du côté J2EE. Je ne peux donc pas te conseiller un framework C++.
Disons que je pourrais considérer ceci comme un bon point de départ, en termes de fonctionnalités offertes (mais attention, je ne l'ai pas testé, je ne peux rien dire de sa qualité)

Citation:

---

Envoyé par clairetj

Je suis en train de parcourir le net pour trouver des réponses à mes interrogations et je voudrais en soulever une ici:
Je croise beaucoup lors de mes recherches les mots "scripts CGI" alors j'ai regardé ce que c'est et de ce que j'ai compris, un script CGI est un programme pouvant être exécuté par le serveur HTTP si ce dernier reçoit une requête de type GET ou POST.

Actuellement, pour développer la partie web j'ai notepad++ et wampserver (oui je suis sous windows). Or wampserver possède déjà un serveur HTTP: Apache.
Par la suite, mon programme sera mis sur une Raspberry Pi qui possèdera elle aussi un serveur HTTP embarqué: lighttpd.

Donc ma question est: est-ce vraiment nécessaire pour moi de rajouter dans mon programme un serveur HTTP ??? Et est-ce que l'utilisation de scripts CGI vous parait adapter à mon utilisation ???

---

Ce pourrait être une solution si tu es prêt à développer une interface de type ligne de commandes pour ton cœur de contrôle d'automate, et si tu maîtrises assez les langages CGI possibles (ex: PHP sur apache, sais tu ce qu'offre lighttpd?)
Sinon, sur la base du lien que je t'ai envoyé ce ne devrait pas être la mer à boire:

• la lib te permet de connaître l'URL appelée => affectes un chemin (l'URL sans le nom d'hôte) à chaque commande
• la lib te donne des clef-valeur qui correspondent aux paramètres de requête, dans lesquels figurent les champs de formulaire soumis => tu extrais les valeurs par les clefs pour connaître les paramètres pour celles de tes commandes d'automates qui prennent des paramètres.

Au risque de passer pour un gros clampin, je vais proposer quelque chose (parce qu'actuellement, pour moi, toutes vos solutions me semble vraiment compliqué à mettre en œuvre au vue de mes maigres connaissance)

Ne serait-il possible d'avoir une page en html dans ce style (c'est un exemple donc la syntaxe ne sera pas bonne)
"j'appuie sur le bouton LED1 => j'envoie un ordre = 1
j'appuie sur le bouton LED2 => j'envoie un ordre = 2
etc ..."

et une simple serveur TCP (le seul serveur qui je sais programme, du moins j'ai un exemple qui fonction) qui marcherait du style:
"selon(ordre reçu)
1 = allumer la LED1
2 = allumer la LED2
etc ...

Disons que ton serveur tourne sur l'hôte serveur.example.com:

• J'appuie sur le bouton LED 1 => j'appelle l'URL http://serveur.example.com/commuterLED&nb=1
• J'appuie sur le bouton LED 2 => j'appelle l'URL http://serveur.example.com/commuterLED&nb=2

Dans la méthode on_request prévue par la lib que je t'ai liée, tu regardes:
que l'URL appelée est commuterLED
A partir de là, tu regardes la valeur associée à la clef "nb", tu la traites comme elle est attendue par ton automate (as-tu une fonction par LED? Y'a t'il un argument int pour un numéro de LED? à partir de la chaîne associée à nb, tu peux faire tout traitement C++ que tu veux faire, ce n'est déjà plus du web...)

Citation:

---

Envoyé par therwald

as-tu une fonction par LED? Y'a t'il un argument int pour un numéro de LED?

---

Oui, j'ai une fonction par LED, voici par exemple les fonctions que j'utilise pour allumer la LED1 et la LED2

Code:

---

1 2 3 4 5 6 7 8 9

void Automate::action_LED1() { sortieTOR[0] = !sortieTOR[0]; }   void Automate::action_LED2() { sortieTOR[1] = !sortieTOR[1]; }

---

Alors ce doit être simple:
à la limite tu fais même des URL séparées pour les différentes LED
Dans la fonction on_request() de ta classe dérivée la classe de serveur tu fais:

Code:

---

1 2 3 4 5

if (incoming.path=="appuiLED1"){ this->automate.action_LED1(); }else if(incoming.path=="appuiLED2"){ this->automate.action_LED2(); }...

---

Il y a là un exemple de code de démarrage de serveur.
Comme tu vois, ça peut être assez simple...
De la même manière que dans le serveur TCP qui te plaisait, tu renvoie ton HTML à afficher comme valeur de retour de ta fonction de traitement. La différence est que tu ne te tappes pas à la main l'implémentation de HTTP (ce qui est nécessaire si tu veux utiliser une page web dans un navigateur comme interface)

par contre questions sur le code que tu m'as donné: http://dlib.net/dlib/server/server_h...ml#server_http

-la partie qui m’intéresse est juste la classe server_http ou c'est vraiment tout le fichier que je dois garder ?
-ce code, j'en fait un copier/coller dans mon programme Qt en créant un nouveau fichier .cpp et .h ?

Là on en arrive à l'organisation du code.
Pour ma part, je créerais 3 compilables (comment, ça dépend de ton environnement de dev):

• une librairie statique = le coeur de contrôle autour de automate
• un exécutable avec l'interface Qt
• un exécutable avec le serveur Web

Chaque exécutable dépend de la librarie statique
Les conseils pour intégrer la librairie sont donnés ici.
Pour être franc, c'est un peu brut de fonderie, mais ça devrait marcher.

Citation:

---

Envoyé par therwald

Là on en arrive à l'organisation du code.
Pour ma part, je créerais 3 compilables (comment, ça dépend de ton environnement de dev):

---

Comme environnement de déeloppement, j'ai code:block que j'utilise réguliérement, ça peut allé ???

Citation:

---

Envoyé par therwald

• une librairie statique = le coeur de contrôle autour de automate

---

Je suppose que pour ce point, on parle de mon programme réalisé sous Qt partie automate (problème: il dépend encore un peu de la connaissance de l'interface pour renvoyer la liste des ports COM disponible)

Citation:

---

Envoyé par therwald

• un exécutable avec l'interface Qt

---

Ici, je suppose que l'on parle de la partie interface de mon programme développé sous Qt

Citation:

---

Envoyé par therwald

• un exécutable avec le serveur Web

---

Il faut donc que je rajoute cete partie qui n'est pas encore faite.

Citation:

---

Envoyé par clairetj

Comme environnement de déeloppement, j'ai code:block que j'utilise réguliérement, ça peut allé ???

---

Jamais testé moi-même, mais pas mal de gens en disent du bien. Si tu le maîtrises c'est l'essentiel.

Citation:

---

Envoyé par clairetj

Je suppose que pour ce point, on parle de mon programme réalisé sous Qt partie automate (problème: il dépend encore un peu de la connaissance de l'interface pour renvoyer la liste des ports COM disponible)

---

Tout à fait. A mon avis tu pourrais rapidement abstraire ta liste de ports (un nom et un code) et confier à ton interface la traduction en terme spécifiques tels que QAction.
Disons que tu remplace la référence à l'interface par une référence à un adaptateur du style:
adaptateur_interface.h (dans le projet automate)

Code:

---

1 2 3 4 5 6

#include <string>   class AdaptateurInterface{ public: virtual void registerPort(const std::string & portName,const std::string & portCode)=0; };

---

adaptateur_qt.h (dans le projet UI Qt)

Code:

---

1 2 3 4 5 6 7 8 9

#include "adaptateur_interface.h" class QmainWindow; class AdaptateurQt: public AdaptateurInterface{ private: QmainWindow * main; public: AdaptateurQt(QMainWindow * interface):main(interface){}; void registerPort(const std::string & portName,const std::string & portCode); };

---

adaptateur_qt.cpp (dans le projet UI Qt)

Code:

---

1 2 3 4 5 6 7

#include "adaptateur_qt.h" #include "mainwindow.h" /* + includes Qt as necessary */ void AdaptateurQt::registerPort { /*code spécifique pour créer une action Qt pour le port, et l'ajouter au menu correct*/ }

---

adaptateur_web.h (dans le projet Webserver)

Code:

---

1 2 3 4 5 6 7 8 9

#include "adaptateur_interface.h" class WebServer; class AdaptateurWeb: public AdaptateurInterface{ private: WebServer * main; public: AdaptateurQt(WebServer * interface):main(interface){}; void registerPort(const std::string & portName,const std::string & portCode); };

---

Et de même un cpp pour implémenter registerPort en terme de création de menu.

Par contre et c'est peut-être une erreur de ma part (sans doute dût à mon imcompréhension) mais tout mes fichiers (automate et mainwindow) sont réunis dans un seul projet CommSerie

Donc quand tu dis projet automate tu parle de automate.h et .cpp ou d'un projet à part entière ???

Ça pourrait être un projet à part entière, mais si déjà tu sépares clairement les composants (la lib et les deux exécutables qui en dépendent), c'est bon.

Donc actuellement, le serveur web devrait être un nouveau projet pour que j'ai un executable pour le serveur. Actuellement lorsque je compile mon projet (automate+interface), j'ai un executable

(désolé mais la je suis en train de me perdre)

Pour l'instant, je n'ai qu'un seul projet nommé CommSerie.pro

Dans mon projet CommSerie.pro, j'ai
automate.h
mainwindow.h
automate.cpp
main.cpp
mainwindow.cpp

Sa veut dire que je dois encore plus séparer les choses ???

Si pour code blocks un projet <-> un binaire, alors tu vas devoir faire un projet automate, un projet mainwindow, un projet serveur web.
Je ne peux pas t'éclairer sur ce point mais il y a sur devp du monde qui connaît code::blocks et qui pourra te débloquer, je pense.

le problème c'est que si j'ai développé sous Qt et pas sur code:block ce n'est pas seulement pour profiter du fait d'avoir une IHM mais aussi toutes les bibliothèques incluses que j'utilise.

Passer sous code::block ne me poserait pas un problème parce que je suppose que je ne peut pas faire un simple copier/coller ???