Discussion :

[Berwazp]

Bonsoir à tous et toutes,

Premier message sur ce site que je vais suivre de très près .

J'aurais besoin, si vous le voulez bien, de votre avis sur ma démarche concernant un projet.
Je m'excuse platement tout d'abord, je suis débutante en programmation. J'espère déjà être dans la bonne section, sinon je réitère toutes mes excuses.


Le contexte : une grosse appli client léger en JSP. Cette appli est prévue pour fonctionner avec des périphériques. Or un périphérique est branché sur un pc client. Normalement le client accède à l'appli Web via son WebBrowser habituel. L'appli Web tape dans une BDD pour connaître quel périphérique le client a associé à son pc. Via Javascript, l'appli Web fait apparaître sur une page JSP un lien (déguisé en bouton par CSS) relatif au périphérique trouvé dans la BDD avec un Id (identifiant) unique.

C'est le pc client où est branché le périphérique qui prends en charge le traitement relatif au périphérique (disons l'apparition d'une boîte de dialogue factice avec le nom du périphérique), quand le client clique sur le bouton de l'appli Web.

La problématique : le pc client doit savoir ce que contient la page Web pour être à l'écoute du "bouton" apparu.
Je n'ai pas le droit d'ouvrir des ports entre le pc client et le Web.

Comment j'ai fais : J'ai développé une appli client lourd en Swing composé d'une JFrame vide et d'un JEditorPane, donc capable de se connecter à l'appli Web, d'afficher ses pages, et de gérer les hyperliens (un navigateur Web en fait, qui ne change rien à l'utilisation de l'appliWeb mais permet de gérer les périphériques).
Je parse l'HTML affiché, détecte l'éventuel "bouton", y ajoute un Listener et au clic du client dessus mon appli client lourd lance la boîte de dialogue factice correspondante.

Bien sûr... L'objet JEditorPane ne gère pas le HTML supérieur à 3.2, quasiment pas le CSS et pas du tout le Javascript. Donc je suis repartie sur JavaFX et sa classe WebView qui gère tout ça bien mieux. C'est juste grave la galère avec le parse du Document affiché (dont je ne suis pas du tout sûre d'utiliser la meilleure méthode), la récupération de l'Id du "bouton" et le Listener... Je trouve très peu d'aides là-dessus sur le net.


Pour vous en dire un peu plus, je suis en stage pour être développeuse Java, et ça c'est ce qu'on m'a demandé de faire. J'aimerais avoir l'avis des gens qui passent par là, pour savoir si la solution choisie tient debout, si vous avez d'emblée pensé à une autre solution, si JavaFX est un bon choix, enfin tout ce que vous auriez envie de me dire sur le sujet .

Une question précise : y'a t-il un moyen de faire communiquer un navigateur Web classique (type FireFox, Chrome, ...) avec son pc ?
J'ai honte je n'y connais rien, mais lorsqu'on clique sur un lien de téléchargement sur le Web par exemple, c'est bien notre pc qui affiche la boîte de dialogue permettant de choisir le dossier de destination du téléchargement ? Ca (mea culpa, je ne sais toujours pas faire les ç majuscules) semble être le fonctionnement dont j'ai besoin, mais je ne trouve rien sur le sujet qui soit exploitable pour mon projet. Quelqu'un sait comment ça fonctionne ? J'imagine qu'il y a des sécurités qui empêchent toute autre autre interaction entre le navigateur et le pc, mais quoi ? Le firewall ?

Si besoin de détails supplémentaires si le sujet vous intéresse, n'hésitez pas je serai à l'affut de vos éventuelles réponses.


Mille merci,

Bonne soirée

[thelvin]

J'aimerais avoir l'avis des gens qui passent par là, pour savoir si la solution choisie tient debout, si vous avez d'emblée pensé à une autre solution, si JavaFX est un bon choix, enfin tout ce que vous auriez envie de me dire sur le sujet .

Étant donné le besoin, ça m'a pas l'air trop déconnant de le faire comme ça si tu dois le faire... Le web est juste pas prévu pour.
Je m'inspirerais de ce que font par exemple DropBox ou Google Drive. Ce sont des sites webs qui aimeraient bien ne fonctionner que comme site web, mais qui ne peuvent pas : pour synchroniser des dossiers entre l'ordinateur et le stockage en ligne il faut que le PC touche beaucoup au dossier local et divulgue au site pas mal d'infos à son sujet... Et un navigateur ne propose aucun moyen de faire ça. De plus il faut pouvoir le faire même quand le site n'est pas ouvert dans un onglet, et les navigateurs ne donnent pas non plus de moyen de faire quelque chose quand le site n'est même pas ouvert.

Donc ils ont décidé de s'éclater en deux partie : un site web, pour faire tout ce qu'un site web sait faire : stockage en ligne, upload/download de fichiers, informations sur les fichiers, restauration à version antérieure. Et un programme annexe, optionnel, à installer par les utilisateurs, qui s'occupe de tourner en tâche de fond et de synchroniser les dossier, sans communiquer avec le navigateur, et en utilisant peu de technologie web (pas de HTML, CSS ou JavaScript. Mais utilisation éventuelle de HTTP via un webservice.)

Une question précise : y'a t-il un moyen de faire communiquer un navigateur Web classique (type FireFox, Chrome, ...) avec son pc ?

La seule solution officielle est de développer un plugin navigateur, de l'installer sur les navigateurs qui s'en serviront, et de faire en sorte que la page l'appelle. C'est difficile, et notamment un plug-in navigateur ne se fait pas en Java.
Après, il existe des spécificités de navigateur. Par exemple avec IE, tu peux utiliser ActiveX ou Silverlight si le site web fait partie des sites "de confiance" listés dans le système de sécurité Windows. Je suppose que d'une manière ou d'une autre ça doit permettre de faire le pont.

lorsqu'on clique sur un lien de téléchargement sur le Web par exemple, c'est bien notre pc qui affiche la boîte de dialogue permettant de choisir le dossier de destination du téléchargement ?

Oui, mais il le fait parce que le site web répond un fichier de téléchargement, et qu'en conséquence, le navigateur dit à l'OS "bon il va falloir sauvegarder un fichier, là, balance une boîte de dialogue pour choisir où et donne-moi le résultat."

Ca [...] semble être le fonctionnement dont j'ai besoin,

Non. Ça n'est pas quelque chose que tu peux exploiter . (Moi sous Windows j'ai carrément créé mon propre layout clavier pour faire les Ç avec AltGr+shift+ç. Je n'arrive pas à retenir les codes.)

J'imagine qu'il y a des sécurités qui empêchent toute autre autre interaction entre le navigateur et le pc,

Oui.

mais quoi ? Le firewall ?

L'absence de mécanisme, pour les sites webs, permettant de demander au pc de faire quelque chose. (Sauf, éventuellement, via l'installation de plug-ins ou extension dans le navigateur, qui ne peut se faire que par l'utilisateur du navigateur ou son administrateur.)
Également un bac à sable dans lequel le navigateur enferme tout ce qu'un site web lui demande de faire, pour que ça ne se fasse qu'à l'intérieur du bac à sable. Ce bac à sable ayant des droits réduits, notamment pas de commander des trucs au pc.

[tchize_]

Moi je trouve ça assez déconnant comme technique

Si tu en viens à développer une appli en local affichant les pages web, autant te passer des pages web et t'affrancher du jsp/servlet et cie pour tout faire en client lourd, avec un serveur pour gérer les données. Ca évitera pas mal d'emmerdes et de confusion.

Restent deux possibilités envisageables relativement propres selon moi:

1) Démarrer une applet dans la page web dont le boulot est de dialoguer avec le périphérique. Tu peux ensuite utiliser du javascript pour échanger des données entre l'applet et le serveur, ou l'applet peut le faire elle même. Avantage: tu peux faire tourner ça dans le browser de l'utilisateur. Au lieu de générer un bouton avec un url spécialisée, tu génèrera un tag applet. J'ai déjà fait ça par le passé pour des lecteurs de cartes d'identité électronique, c'est un peu chiant à mettre en place au départ, mais c'est très propre pour l'utilisateur.

2) créer un plugin traitant ton propre protocole et l'installer sur chaque machine. Tu peux ainsi créer des urls de type peripherique://id_du_peripherique/?param1=val1&param2=val2. Ca se fait par exemple ici https://addons.mozilla.org/en-US/fir...rotocol-handl/

[thelvin]

1) Démarrer une applet dans la page web dont le boulot est de dialoguer avec le périphérique. Tu peux ensuite utiliser du javascript pour échanger des données entre l'applet et le serveur, ou l'applet peut le faire elle même. Avantage: tu peux faire tourner ça dans le browser de l'utilisateur. Au lieu de générer un bouton avec un url spécialisée, tu génèrera un tag applet. J'ai déjà fait ça par le passé pour des lecteurs de cartes d'identité électronique, c'est un peu chiant à mettre en place au départ, mais c'est très propre pour l'utilisateur.

Tiens je m'étais plus ou moins figuré qu'une applet ne pourrait pas accéder au matériel comme ça. Ça m'embête d'ailleurs de découvrir que si je réinstalle le plug-in Java, des sites pourraient le faire.

[tchize_]

A partir du moment où elle est signée et a demandé tous les droits, oui. Evidement, l'utilisateur devra donner ces droits

[thelvin]

Hmm, mais bon, si ces droits se donnent avec une pop-up "concours de celui qui clique le plus vite sur 'Oui' en ayant le temps de lire le moins de mots possibles," je ne risque pas grand-chose. Mais mes concitoyens -_-° ...

[tchize_]

Si le problème est juste l'utilsiateur trop con pour lire un message d'avertissement en grand, gras avec du rouge, nécessitant de cocher une case et de cliquer sur ok, je crois que tu as plus de crainte à avoir avec les .exe en téléchargement

[elmor]

Franchement je ne comprends pas bien le problème. Pourquoi faire un client lourd ?


Le problème est comment le PC de l'utilisateur informe l'appli des services qui sont installés sur sa machine ?

SI tu ne peux pas ouvrir de port en plus du port HTTP, tu peux tout faire passer par le HTTP en utilisant le protocole REST

Pour moi si tu veux rester en client léger tu peux installer un mini serveur web en local (il est possible d'intégrer complétement le serveur web dans ton appli)
Ensuite ton browser tape sur des pages en local et au niveau de ton mini serveur tu fais une requête HTTP en rajoutant les paramètres qu'il faut pour obtenir la page JSP qui tu renvoies, en rajoutant un listener javascript pour le click sur les boutons.


Le sujet est super étrange pourquoi devoir faire des listeners sur des pages qui ne sont pas les notres ...
Le serveur de JSP ne pourrait-il pas automatiquement rajouter les bon liens si le client envoie les informations sur les périphériques connectés (IP/PORT ...)?
Le mieux est que les périphériques embarquenbt aussi des mini serveur web
...

[thelvin]

Si le problème est juste l'utilsiateur trop con pour lire un message d'avertissement en grand, gras avec du rouge, nécessitant de cocher une case et de cliquer sur ok, je crois que tu as plus de crainte à avoir avec les .exe en téléchargement

J'ai des craintes à avoir, mais pas "plus." L'utilisateur moyen a acquis une certaine conscience du fait que s'il va chercher un programme sur Internet, et clique dessus, il a de bonnes chances d'avoir ainsi installé son propre "virus" malgré son "antivirus" pourtant silencieux.
Une simple pop-up qui apparaît sur un site, par contre, c'est différent. Les gens ont l'habitude de pop-ups inutiles qui apparaissent pendant qu'ils utilisent un programme, et soit sont littéralement inutiles du genre "nous vous informons que vous venez de changer de vue, cliquer ici pour pouvoir continuer à travailler," soit sont des avertissements de sécurité comme "nous vous informons que cette opération peut présenter un risque de sécurité si elle est faite par quelqu'un qui n'est pas du tout dans votre situation et qui ne s'en sert pas dans le même contexte encadré que vous. Nous vous en informerons à chaque fois bien qu'elle soit indispensable pour votre travail."

[Berwazp]

Merci pour vos réponses .

Je vais développer un peu pour justifier le choix de ma solution, vous me direz si ça tient un peu plus la route :

Les clients sont hyper-exigeants .
L'application Web est déjà vendue en tant que pur client léger. Le client l'adopte parce que l'un des avantages d'un client léger est qu'il n'y a pas d'installation sur le poste (pas besoin de payer les dév pour qu'ils installent et configurent l'appli sur toutes les machines (parfois des centaines selon les clients de la boîte), pas besoin de faire intervenir le service info pour donner les droits administrateurs aux installateurs, ...).

Evidement, l'utilisateur devra donner ces droits

Cette appli concerne la sécurité, donc clients avec de gros sites genre zones sensibles, donc droits sur les PC quasiment inexistants, ce qui explique également l'interdiction d'utiliser des ports de communication.

Pourquoi faire un client lourd ?

La boîte propose la possibilité d'utiliser des périphériques avec cette appli. Mais cette nouvelle fonctionnalité doit être parfaitement transparente pour le client, ne rien changer aux habitudes des employés qui utilisaient déjà l'appli Web : pas d'application qui s'ouvre, genre en tout petit et que les utilisateurs pourraient fermer.

Ma solution est donc (si mes recherches sont exactes), un client riche : la simulation d'un navigateur Web faisant fonctionner l'appli Web (on ne va pas la refaire en client lourd, c'est une appli énormissime gérée loin loin loin sur un énorme Hub) avec en plus le code nécessaire à la gestion des périphériques branchés sur le poste.

Le problème est comment le PC de l'utilisateur informe l'appli des services qui sont installés sur sa machine ?

Je n'ai pas encore géré ça mais ce que j'en sais : de l'appli Web, l'utilisateur "associe" ses périphériques à l'application. Le code JavaScript côté serveur rempli une BDD avec le paramétrage des périphériques, leur nom, etc., puis transmet les infos au client lourd qui gère ça tout seul.

L'absence de mécanisme, pour les sites webs, permettant de demander au pc de faire quelque chose. (Sauf, éventuellement, via l'installation de plug-ins [...]
Également un bac à sable dans lequel le navigateur enferme tout ce qu'un site web lui demande de faire, pour que ça ne se fasse qu'à l'intérieur du bac à sable. Ce bac à sable ayant des droits réduits, notamment pas de commander des trucs au pc.

Voilà. Mon projet est bac à sable, c'est exactement ça. Un utilisateur de l'appli Web n'a qu'à cliquer sur un lien de l'appli Web pour lancer l'installation du client lourd de la même façon qu'un plugin qu'on ajoute à son navigateur. Sauf que dans mon cas ça ajoute un raccourci sur le bureau que l'utilisateur utilisera désormais pour accéder à son application habituelle : il ne saura pas qu'il n'utilise plus son navigateur, mais le mien, customisé pour gérer les périphériques XD. D'où le client lourd avec interface graphique en JavaFx, il faut que ça ressemble trait pour trait à un navigateur Web.