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

Navré, mais à te lire je croyais que tu étais déjà sous code::blocks.
Si tu es adhérent à Qt créator, restes sous Qt créator pour l'instant. Mais il n'en reste pas moins qu'il te faut créer 3 compilables, comme je l'ai dit précédemment, c'est simplement les détails de l'opération qui diffèrent. Je ne connais pas plus Qt créator, ceci dit.

Citation:

---

Envoyé par moi

Je ne peux pas t'éclairer sur ce point mais il y a sur devp du monde qui connaît code::blocks Qt créator et qui pourra te débloquer, je pense.

---

Un exemple, j'ai mon programme Qt tel qu'il est actuellement:
1 exécutable qui lorsque je le lance, fait ce qui ce passe dans mon main (création d'un objet de classe automate, création de objet de classe mainwindow qui connait mon objet automate, prise de connaissance de la mainwindow par l'interface pour pouvoir récupérer sur l'interface la liste des ports COM)

Code:

---

1 2 3 4 5 6 7

QApplication a(argc, argv); Automate automate; MainWindow window(&automate); automate.setInterface(&window); window.show();   return a.exec();

---

Etant donné que je vois ce programme tourner continuellement en fond (chose que j'ai sans doute oublié de préciser) ne serait-il pas plus simple de juste rajouter dans mon programme la création d'un serveur qui fera la passerelle entre la page web et mon programme que de crée 1 executable pour mon automate, 1 executable pour mon serveur, etc ... ???

C'est indubitablement plus simple. En fait j'avais mal cerné ton environnement. Je suppose que ton environnement final pour déployer aura une couche graphique, qu'on pourra choisir entre ouvrir une session graphique locale pour piloter directement ou se connecter à distance en web.
EDIT: mon message est ambigü: j'avais conseillé le découpage en 3 en supposant que le serveur web ne serait pas exécuté sur le même environnement que l'interface Qt. Dans ce cas avoir juste le serveur Web permet de faire tourner le programme de contrôle d'automate sur un environnement plus léger (entre autres, pas de couche graphique), sachant que de base un exécutable graphique refuse de tourner en l'absence de couche gaphique.

Citation:

---

Envoyé par therwald

C'est indubitablement plus simple. En fait j'avais mal cerné ton environnement. Je suppose que ton environnement final pour déployer aura une couche graphique, qu'on pourra choisir entre ouvrir une session graphique locale pour piloter directement ou se connecter à distance en web.

---

En faite, l'idée serait de ne pas à avoir à intervenir sur la partie "serveur" pour commander mon automate donc plutôt se connecter à distance via navigateur web. Par contre, où cas où il y aurait des modifications/erreurs il faudrait avoir la possibilité de faire des tests directement sur la partie "serveur" (quand je dit serveur ici, je parle du PC ou de la carte qui abrite mon programme et qui est connecté à mon automate).

En gros, garder l'interface Qt pour lorsque l'on va directement intervenir sur la machine serveur (chose qui normalement sera super rare et donc si l'écran est éteint ou pas d'écran du tout, un faible risque de faire quelque chose sur l'IHM Qt) mais avoir aussi la possibilité de commander à distance (après à moi de voir si je fais une sécurité en disant: "si quelqu'un est connecté directement sur la machine serveur personne ne peut passer par internet et vice versa).

Donc le fait de ton incompréhension viens totalement de moi, je n'avais pas donné toute les informations et mes idées. C'est pour cela qu'avec l'idée que je me faisais je trouver que cela devenait vachement compliqué



Du coup, pour en revenir à la question qui tue: comment faire ?
J'ai ouvert un topic sur le forum et qu'il ma proposé une idée qui fonctionnerait comme ceci:

Citation:

---

1. Tu clics sur le bouton

2. Le navigateur va charger la page WEB en ce connectant au server lighttpd ou wamp

3. Le serveur (lighttpd ou wam pour les essais en local) analyse la requête et exécute le script PHP adéquate

4. Le script PHP se connecte à ton serveur Qt et envoie une commande

5. Le serveur Qt exécute la commande

6. Le script PHP génère la page

7. Le serveur (lighttpd ou wam pour les essais en local) renvoie la page au navigateur

---

Est-ce que cela te parait logique et du coup je suppose que c'est un peu plus simple que jusqu'à maintenant

Citation:

---

Envoyé par clairetj

Du coup, pour en revenir à la question qui tue: comment faire ?
J'ai ouvert un topic sur le forum et qu'il ma proposé une idée qui fonctionnerait comme ceci:


Est-ce que cela te parait logique et du coup je suppose que c'est un peu plus simple que jusqu'à maintenant

---

J’en pense que ça ressemble à une solution de développeur web :aie:. C’est absolument pas maintenable comme modèle (je parle d’expérience : j’ai bossé sur une appli qui fonctionnait comme ça, c’est l’enfer). Il manque aussi une étape très importante :

Citation:

---

4. Le script PHP se connecte à ton serveur Qt et envoie une commande

---

==> Comment ?

Répondre à cette question te fera voir qu’en fait, ça n’est pas plus simple que les autres solutions proposées.

Note : le projet qu’on t’a donné est assez ambitieux. Avoir deux interfaces distinctes, fonctionnant en même temps, pilotant le même programme, est loin d’être trivial à faire pour un étudiant

Note 2 : où en es-tu de la séparation automate / interface ? Il te restait une dépendance au niveau de la création des menus, as-tu réussi à la supprimer ? (indice : une solution possible est de passer par une classe abstraite dont hériteraient ensuite tes classes d’interface).

Citation:

---

Envoyé par white_tentacle

Il manque aussi une étape très importante :



==> Comment ?

Répondre à cette question te fera voir qu’en fait, ça n’est pas plus simple que les autres solutions proposées.

---

+1
Avec ça tu vas te retrouver à faire 2 serveurs ou services en cascade au lieu d'un...

Citation:

---

Envoyé par white_tentacle

Note : le projet qu’on t’a donné est assez ambitieux. Avoir deux interfaces distinctes, fonctionnant en même temps, pilotant le même programme, est loin d’être trivial à faire pour un étudiant

---

Oui je me rend bien compte que c'est très loin de mes connaissance :oops:

Citation:

---

Envoyé par white_tentacle

Note 2 : où en es-tu de la séparation automate / interface ? Il te restait une dépendance au niveau de la création des menus, as-tu réussi à la supprimer ? (indice : une solution possible est de passer par une classe abstraite dont hériteraient ensuite tes classes d’interface).

---

Pour ce qui est de la dernière interdépendance, je n'ai toujours pas réussi à la supprimer (et je ne vois pas comment faire malgré ton indice)

Du coup avec les nouvelles données que j'ai indiqué (que j'aurais du indiquer dès le départ et je m'en excuse encore), à savoir que mon programme se destine à tourner en fond (lancer perpétuellement sauf si arrêt de la carte ou PC) il serait donc plus simple à mettre en œuvre => comment faire maintenant ?

Le fait d'avoir le fonctionnement "perpétuel" me permet (dans ma pensée) d'avoir un serveur (qui sera tout le temps en fonctionnement vu que rattaché au programme, il fonctionne lui aussi "perpétuellement") pour faire ma passerelle.

Après pour le fait d'avoir les deux interfaces lancé en même temps, pilotant le même programme, c'est vrai que je n'ai est pas trop songé. je suis parti du principe que si l'on pouvait commander le programme depuis internet, on a pas besoin d'intervenir directement sur la machine donc même si l'interface graphique est lancée sur la machine, personne ne s'en sert (je sais pas sije suis compréhensible)

Citation:

---

Envoyé par white_tentacle

==> Comment ?

---

Ne pourrais-je pas passer par un (une ???) socket php qui me permettrais de me connecter au serveur

Pour le fait d'avoir 2 serveur au lieu d'un, peutêtre que je peux apporter un peu de lumière (ou alors c'est moi qui est pas compris). Actuellement je construit mon interface web avec notepad et wampserver, je teste donc en local (wampserver me donne un serveur apache) donc cela me fait déjà 1 serveur. Il faudrait un deuxième serveur pour faire le lien entre mon programme et la page web (si j'ai bien compris) donc au final j'ai bien deux serveurs

Le rpojet (une fois que ça marche en local) sera mis sur une raspberry pi qui aura un serveur embarqué lighttpd (qui aura la même fonction que mon serveur local apache) donc j'aurais toujours eux serveurs (ou alors comme je l'ai dit, j'ai vraiment rien compris)

Tu peux faire comme ça (c’est à dire, un serveur web pour l’interface, et ensuite, un serveur tcp dans l’application pour communiquer avec les scripts php). Mais ce n’est pas la seule solution, et honnêtement, ça rajoute de la complexité. Réfléchis bien à toutes les informations que tu vas devoir échanger échanger entre le script php et ton programme, et tu verras que ça ne va pas être trivial à implémenter.

Maintenant, je ne sais pas où tu en es vis à vis de l’avancement de ton interface. Si tu n’as fait que quelques boutons en html, et bien ma foi, ça vaut probablement vraiment le coup de te poser une journée pour voir si tu ne peux pas plutôt utiliser cppcms (le tutoriel a l’air assez détaillé quand même).

Citation:

---

Envoyé par clairetj

Pour le fait d'avoir 2 serveur au lieu d'un, peutêtre que je peux apporter un peu de lumière (ou alors c'est moi qui est pas compris). Actuellement je construit mon interface web avec notepad et wampserver, je teste donc en local (wampserver me donne un serveur apache) donc cela me fait déjà 1 serveur. Il faudrait un deuxième serveur pour faire le lien entre mon programme et la page web (si j'ai bien compris) donc au final j'ai bien deux serveurs

---

Il te faudra de toute façon un serveur C++.
Soit ton serveur web C++ renvoi des données brutes (type json) et un deuxième serveur web (ex. Apache) les utilise pour générer la page web, soit ton serveur web renvoi directement une page web (ce qui n'est pas plus compliqué : une fois que ta codé un serveur web, renvoyer du json ou du html, c'est la même chose).
Il n'y à pas vraiment d’intérêt ici à avoir un intermédiaire.

Citation:

---

Envoyé par clairetj

Oui je me rend bien compte que c'est très loin de mes connaissance :oops:



Pour ce qui est de la dernière interdépendance, je n'ai toujours pas réussi à la supprimer (et je ne vois pas comment faire malgré ton indice)

---

L'indice de white tentacle te propose de créer une classe abstraite (en gros, la classe mère d'adaptateur dont je parlais quelques post plus haut, et qui serait le type de l''argument de la méthode init indépendante de Qt), puis de faire dériver les interfaces de cette classe.

Citation:

---

Envoyé par white_tentacle

Tu peux faire comme ça (c’est à dire, un serveur web pour l’interface, et ensuite, un serveur tcp dans l’application pour communiquer avec les scripts php). Mais ce n’est pas la seule solution, et honnêtement, ça rajoute de la complexité. Réfléchis bien à toutes les informations que tu vas devoir échanger échanger entre le script php et ton programme, et tu verras que ça ne va pas être trivial à implémenter.

Maintenant, je ne sais pas où tu en es vis à vis de l’avancement de ton interface. Si tu n’as fait que quelques boutons en html, et bien ma foi, ça vaut probablement vraiment le coup de te poser une journée pour voir si tu ne peux pas plutôt utiliser cppcms (le tutoriel a l’air assez détaillé quand même).

---

Pour ce qui est de l'interface web en elle même, oui elle se résume actuellement à de simple boutons en html donc question:
cppcms ???

Je reviens sur un point précédent, tu me dit que pour enlever la dernière interdépendance entre ma partie automate et la partie interface (renvoyer sur l'interface la liste des ports disponible et dire depuis l'interface sur quel port on a choisi de travailler), il faudrait que j'utilise une classe abstraite, je n'en est jamais utiliser donc cela reste quelque chose de vague donc moi et tu dis "dont hériteraient ensuite tes classes d’interface" (je n'ai qu'une classe interface donc ce doit être une erreur de frappe), il faudrait donc que ma classe abstraite soit une classe mère par rapport à ma classe d'interface. Mais je ne vois pas comment cela résoudra mon problème

Citation:

---

Envoyé par therwald

L'indice de white tentacle te propose de créer une classe abstraite (en gros, la classe mère d'adaptateur dont je parlais quelques post plus haut, et qui serait le type de l''argument de la méthode init indépendante de Qt), puis de faire dériver les interfaces de cette classe.

---

donc si je comprend bien (et on suppose que j'ai créé ma classe abstraite, chose qui n'est pas encore gagné pour moi) donc mon main

Code:

---

1 2 3 4 5

QApplication a(argc, argv); Automate automate; MainWindow window(&automate); automate.setInterface(&window); window.show();

---

je remplace le window dans la ligne automate.setInterface(&window) par ma classe abstraite ???

J'en profite au passage pour m'excuser au près de vous, je vous garanti que je fais tout les efforts du monde pour essayer de comprendre ce que vous m'expliquer et je dois certainement passer pour un glandu à vos yeux et que vous avez sans doute l'impression de perdre votre temps avec moi mais je vous jure que je m'efforce réellement de vous comprendre lorsque vous m'expliquer quelque chose

Citation:

---

Envoyé par clairetj

donc si je comprend bien (et on suppose que j'ai créé ma classe abstraite, chose qui n'est pas encore gagné pour moi) donc mon main

Code:

---

1 2 3 4 5

QApplication a(argc, argv); Automate automate; MainWindow window(&automate); automate.setInterface(&window); window.show();

---

je remplace le window dans la ligne automate.setInterface(&window) par ma classe abstraite ???

---

Il faut que tu bosses les cours sur la programmation OO. Ici tu dois comprendre qu'on utilise le principe de substituabilité: si tes deux interfaces dérivent de la même classe abstraite, une instance de n'importe laquelle des deux classes d'interface peut être fournie là où on demande une référence ou un pointeur du type de la classe abstraite.
Donc, pour répondre dans le cas présent, non tu ne changes pas la ligne

Code:

---

automate.setInterface(&window)

---

, qui reste valide. Tu changes la déclaration de setInterface de

Code:

---

void setInterface(MainWindow & window);

---

en

Code:

---

void setInterface(AbstractInterface & iFace);

---

Tu fais en sorte que la définition de registerPort dans ta classe abstraite soit suffisamment générale (à mon avis un nom de port à afficher et un code d'identification de port ça suffit) pour permettre à l'interface Qt ou au serveur web de l'implémenter.
A la suite de ça, tu pourras aussi écrire quelque chose du genre:

Code:

---

1 2	InterfaceWeb ifaceWeb(&automate); automate.setInterface(&ifaceWeb);

---

Par la suite, puisque tu veux les deux interfaces à la fois dans le même exe, soit il est techniquement possible d'avoir deux instances d'automate en même temps (mais à vrai dire je ne ferais pas le pari...) soit tu changes setInterface() en addInterface() et tu fais en sorte que la dernière interface ajoutée ne remplace pas l'autre. Ça suppose de vérifier dans quels cas sont faits les callback de l'automate vers l'interface, et de s'assurer que ces apples peuvent être faits vers n (ici 2) interfaces au lieu d'une.

Citation:

---

Envoyé par clairetj

et tu dis "dont hériteraient ensuite tes classes d’interface" (je n'ai qu'une classe interface donc ce doit être une erreur de frappe), il faudrait donc que ma classe abstraite soit une classe mère par rapport à ma classe d'interface. Mais je ne vois pas comment cela résoudra mon problème

---

Il faut que tu te poses et que tu essaie de clarifier tes notions de conception. Une interface ce n'est pas forcément une fenêtre, c'est n'importe quoi qui permet un lien entre un agent extérieur (parfois humain, parfois un process tiers ou une machine) et ton logiciel.
Donc non tu n'as pas une interface mais DEUX:

1. l'interface Qt
2. le serveur web

Je suis en train d'essayer de faire ma classe abstraite et voici où j'en suis pour l'instant:

abstractInterface.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#ifndef ABSTRACTINTERFACE_H #define ABSTRACTINTERFACE_H   #include <QString> #include <QFile> #include <QAction> #include <QMenu>   class Automate;   class AbstractInterface { public: explicit AbstractInterface(Automate* automate); ~AbstractInterface();   virtual void ajouterAction(QAction* action) = 0; virtual void ajouterMenu(QMenu* menu) = 0; };     #endif // ABSTRACTINTERFACE_H

---

abstractInterface.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include "automate.h" #include "mainwindow.h" #include "abstractInterface.h" #include "ui_mainwindow.h"   AbstractInterface::AbstractInterface(Automate* automateParam) {   }   AbstractInterface::~AbstractInterface() {   }

---

et donc dans mon mainwindow.h j'ai ça lorsque je déclare ma classe:

Code:

---

class MainWindow : public QMainWindow, public AbstractInterface

---

donc est-ce que je suis sur la bonne voie ???

Tu es sur la bonne voie. Il faut que tu fasses quelque chose du paramètre automate (alimenter un pointeur private avec getter protected par ex), sinon c'est bien l'idée.

Citation:

---

Envoyé par therwald

Tu es sur la bonne voie. Il faut que tu fasses quelque chose du paramètre automate (alimenter un pointeur private avec getter protected par ex), sinon c'est bien l'idée.

---

donc rajouter dans mon .h

Code:

---

1 2 3

private: Automate* m_automate;

---

et dans mon .cpp dans le constructeur, lui dire

Code:

---

m_automate = automateParam;

---