Discussion :

[clairetj]

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 ???

[white_tentacle]

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.

[clairetj]

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)

[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 ???

[therwald]

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é)

[therwald]

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.

[clairetj]

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 ...

[therwald]

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...)

[clairetj]

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 :

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

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];
}

[therwald]

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 :

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

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)

[clairetj]

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 ?

[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):

• 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.

[clairetj]

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é ???

• 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)

• 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

• un exécutable avec le serveur Web

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

[therwald]

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.

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 :

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

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 :

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

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 :

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

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 :

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

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.

[clairetj]

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 ???

[therwald]

Ç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.

[clairetj]

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)

[clairetj]

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 ???

[therwald]

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.

[clairetj]

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 ???