Salut
 
Voici en qques mots ma question... j'aurais une application serveur en Java et j'aimerais savoir si avec Java il est possible de récupérer le contenu d'un formulaire html ? et si oui comment ?
 
merci d'avance

Oui c possible, je me souvient plus trop des détails(je l'ai fais qu'une fois) tu doit donner un nom à chaque "entrée" du formulaire et tu poura récupérer sa valeur dasn ta servelet grace à ce nom.

justement, je ne veux pas utiliser de servlet, mais une application Java qui tournerait en continue a l'écoute d'un port spécifique sur lequel arriverait le formulaire de l'utilisateur.

C'est exactement le rôle d'un conteneur de servlet. Mais bon si tu veux faire ça toi-même, il va falloir parser la requete HTTP ; donc il faut que tu te documente sur la structure d'une requete HTTP.

merci pour vos réponses.
 
Mais a moins que je me trompe, les servlets, ca marche de la même façon que le JSP ou le PHP par exemple nan ? C a dire que ce sont des scripts qui s'exécutent à la demande du client. Dans mon cas, l'application Java que j'aurai a développer sera un serveur (un exécutable) et non juste un script tournant sur un serveur PHP. C'est pour ca que je voudrais pouvoir récupérer le contenu d'un formulaire depuis une application Java autonome.
 
S'il n'y a pas d'autres solutions, je tenterai en effet de parser la requete HTTP comme le dit R3g.

Non une servlet c'est un peu plus que ça. Une servlet c'est une classe dont les objets sont instanciés par un serveur qui est le conteneur de servlets. Le conteneur écoute un port, reçoit les requetes HTTP, les parse, instancie des objets pour les representer, et passe ces objets à la servlet qui fait le traitement approprié. En gros ca fait ce que tu veux faire, et bien plus : redirections, gestion des sessions, etc.

 
A priori, je n'vois pas pourquoi tu refuserai d'utiliser une servlet (si le rôle de ton appli est de traiter de formulaires HTTP, je n'vois pas pourquoi ça ne devrait pas être une servlet).  Heu, aussi, une Servlet, ça tourne pas sur un serveur Php !  
Et puis, si tu n'veux pas faire de Servlet, c'est évident qu'il n'y a pas d'autre solution que de décortiquer à la main les requètes HTTP qui tu recevras...

quand je comparais a PHP, c t sur le principe...
 
En fait, ce qui me bloque a utiliser des servlets c que l'interface via formulaire c juste un outil pratique... mon application devra piloter des appareils branchés sur le port série, envoyer des signaux, en recevoir... Et je ne pensais pas que les servlets puissent faire cela, et g un peu de mal a le concevoir mais c vrai que mes connaissances niveau servlets sont pas top...

Les servlets c'est pas incompatible avec ce que tu veux faire, au contraire, d'aillerus je l'ai deja fait, mais attention au design !

je te remercie... ca me fait donc une piste intéressante
 
Tant que tu es là je v en profiter un peu  
 
J'aimerais savoir comment tu t'y prends pour organiser le tout... Déjà pour les servlets, il faut un serveur HTTP qui tourne sur lequel on pose les servlets. Mais a ce moment là, comment je fais la liaison entre mes servlets et mon appli Java qui gère le port série et compagnie ? c là que qque chose me semble flou : d'un coté g mon appli qui tourne en continu, de l'autre des servlets qui s'exécutent quand une requete cliente les appelles. Mais comment une requetes sur une servlet peut générer un évènement dans mon appli Java (ex : émission d'un signal sur le port COM).
 
merci en tout cas

Bon tu as un serveur, genre Tomcat, Resin ou autre... qui tourne en permanence et qui reçoit les requetes HTTP. Ces requetes sont transmises à la servlet.
Dans la servlet, tu recupère les paramètres de la requete, et tu agit en consequence. Il ne faut pas oublier que ta servlet est un objet java comme un autre ; donc il suffit d'instancier les objets qui vont bien, lancer des threads, etc. pour que ton traitement se passe bien.
Apres tout depends de ce que tu fais exactement avec le port COM. Si tu ne transmet des infos que quand tu reçoit une requete ou si ca tourne en continu, si les traitements sont plutot cours ou plutot long, si plusieurs utilisateurs sont susceptibles de demander un traitement en même temps....
Commence par lire une paire de tutoriaux sur les servlets pour bien comprendre le principe, après ca ira mieux. Le truc c'est de ne pas oublier que la servlet n'est qu'une interface avec ton appli, et donc de ne pas trop les rendre dépendantes l'une de l'autre. Le consile que je pourrais te donner, en tout cas c'est ce que j'ai fais comme je n'était pas trop sur de mon design, c'est de concevoir, parallèlement à la servlet, une interface locale (genre swing) à ton appli. Comme ça tu évitera les grosses erreurs qui consistent à faire trop de traitement métier dans la servlet.

R3g > Encore une fois merci pour toutes ces informations, je v me renseigner sur tout ca, c une bonne base de départ.
 
Merci

le problème que je vois c'est qu'actuellement tu as un programme que tu lances dans lequel tu voudrais ajouter la possibiliter de recevoir des requêtes HTTP.
 
Si tu veux passer en servlets, il va falloir que tu intègres ton prgrammes au sein des servlets. Ce ne sera plus ton programmes que tu lanceras, mais le serveur web (ex:tomcat) qui lui instenciera lanceras les objets de ton programme ...
 
Ce n'est pas fircément un problème mais c'est un changement d'architecture qu'il faut prendre en compte.
 
Si tu choisis de gérer à la main la receptino de donénes de formulaire Web, sache que ce n'est pas trop compliqué (faut quand même connaître un minimum le HTTP), mais que le plus dur sera surement d'afficher la page de résultat (la page suivant ton formulaire) dans le cas où elle contient des données dynamique (que ce n'est pas une bête page statique quoi).
 

 
Euh pourquoi utiliser Tomcat quand il a uniquement besoin de recuperer des données d'un form ??  
 
Un simple service http en Java multi-thread (p'tit papoose quoi) ca suffit amplement... Ca tient en qqs classes et c'est pas long a faire (@see java.net), en plus il doit avoir des ex fonctionnels un peu partout (ie o'reilly). Apres a voir la complexité de tes pages... Ca reste du html
 
Se prendre la tete avec Tomcat + une interface Swing... J'opte directement pour Swing. M'enfin, y'en a qui aime se compliquer les choses des fois...

L'interface swing c'était pas pour la faire : juste y penser pendant la conception pour bien gerder à l'esprit le découplage interface/logique.
Il y a peut-être plus léger que Tomcat pour faire tourner des servlets, mais s'em***** à faire son propre serveur pour recevoir les requetes, répondre, gérer les erreurs et tout et tout, je vois pas l'interet. Surtout que comme je l'ai dit, si l'appli se complique un peu, rien que pour la gestion des sessions, c'est carrement plus simple d'utiliser un serveur tout fait.

benou > c bien ce qu'il me semblait : utiliser les servlets me force à intégrer mon programme dans les servlets et a revoir l'architecture de toute l'appli. Et je tiens quand même a mon programme autonome Le coté interface Web n'est pas la partie principale du programme...
 
benou, Senternal, R3g, je v suivre un peu toutes vos remarques pour voir ce qui correspond le mieux a mon besoin. Si vous avez d'autres idées, n'hésitez pas
 
merci

Y aura bcp de pages html dynamiques à gérer ?
tu vas devoir gérer des sessions (identification, etc ...)
 
le problème après c'est de maintenir ce genre de truc. Essaye de faire ca proprement, avec des templates HTML par exemple ...

La question alors c'est que fait ton programme en plus de repondre aux requetes des utilisateurs ? Quel genre d'interface utilisateur tu utilises pour l'instant ?
Dans certains cas, le passage à une architecture webapp peut être très simple : ton main est remplacé par une routine lancée au démarrage de tomcat, et ton interface utilisateur est remplacée par des servlets et éventuellement des JSP.
Ceci dit, si l'interface web n'est pas une caractéristique essentielle de ton appli, c'est sur qu'il est possible de faire beaucoup plus simple.

d'après ce que j'ai compris, il veut juste laisser la possibilité de configurer 2 ou 3 trucs à distance avec une interface web ...

Sinon si tu veux garder le côté "standalone" de ton appli, peut-être que JMS est fait pour toi... Mais là encore, ca doit être plutôt lourd à intégrer.

Oue, je sais, j'y vais fort. Mais avec cette chaleur...

ouais quand même ... on est pas sur 01net ici !

bah, sinon, tu peux faire une communication entre tes deux programmes...Ca me paraitrait meme le plus souple à terme : dans ton programme existant , tu ajoutes un "serveur d'administration" (a toi de choisir quel type de truc..Pour qqchose de simple, une bete socket suffirait) et tes servlets (ou n'importe quoi d'autre, du coup) n'a qu'à envoyer des commandes à ce serveur....
J'ai fait à peu près ça pour monitorer un serveur de modération pour du chat : l'interface de configuration/stats, c'est des servlets, et y'a qques boutons (genre reload, restart, etc..) qui permettent de mettre à jour le serveur de façon dynamique : en gros, ça lui envoie une commande, et il agit en conséquence, pour recharer sa conf, modifier le niveau de log, etc... sans redémarrage.

R3g > c comme Benou a dit...  
 
En gros j'ai une application qui devra gérer tout plein de trucs (en relation avec le port série, donc envoi de signaux). On pourra la paramètrer en local mais j'aimerais avoir accès a qques paramètres via une interface Web.
 
Donc les formulaires ca serait le plus simple... Sinon y a aussi la possibilité d'écrire un applet Java qui se lancera par le navigateur et se connectera au serveur. Mais c déjà plus lourd coté client.
 
gfive > ce que tu proposes c de faire une liaison entre l'application qui gère le port série et l'application qui tournerait sur le serveur web (en ouvrant une socket sur l'application port série qui attendrait une connexion en provenance du serveur web) ?
 
 

je me permetde répondre à sa place : oui c'est ca qu'il a voulu dire.
C'est en effet une bonne solution

héhé merci

bien vu benou!
A c't'heure, je regardais Pau-Orthez se prendre une raclée contre Villeurbanne....Mais je serais à Pau Samedi, nondidiou!!