continuation de la la discute du topic copier/coller
 

 
je vois pas le lien avec get ou post, mais si tu veux faire pareil en java dans une servlet, tu as juste à surcharger la méthode service à la place de doGet ou doPost.
Si tu fais des JSP, c'est comme en PHP : tu t'en fous.
 
ensuite pour récupérer les fichiers en java ca prend 2 lignes aussi :  

 
vraiment, je vois pas la difficulté ... C'est juste que PHP gère le fileupload en standard alors que java considère que c'est un extension (ce qui est vrai).

1- Tu oublie le try / catch
2- Tu oublie de tester si le fichier est sur disque ou en mémoire pour l'écrire ailleur.
3- Tu oublie d'écrire le fichier ailleur
 
Et si par malheur tu as aussi un champs text, ben il sera pas accessible par getParameter...
Pourquoi ?
 
PS : On recommence la discussion depuis le début c'est ça ?

1/ si t'es dans une jsp pas besoin
2/ pas bien compris ...
3/ Tu peux utiliser la méthode parseRequest du DiskFileUpload :
upload.parseRequest(request, yourMaxMemorySize, yourMaxRequestSize, yourTempDirectory);
 
Après c'est de la config fine en fonction de ce que tu veux en faire du fichier que tu reçois ... Pour ca faut configurer le DiskFileUpload, ca prendra quelques lignes de plus mais tu ne le feras qu'une fois par appli...

1- J'ai pas le droit de faire du java dans les JSP...
2- DefaultFileItem.isInMemory()
3- Je voulais parler de copier le fichier à sa destination finale.
Bref on est loin des 2 lignes.
Mais c'est bon là, ma méthode fonctionne, je trouve ça chiant c'est tout !
 
Bon çà donne :

d'un autre côté en programmant un peu objet, tu serais pas obligé de taper l'appel à ton truc à chaque fois, contrairement à du php

C'est le cas
Cette méthode est appelée automatiquement dans la classe générique ActionBean dont hérite toutes les classes de la couche de présentation.
Dans cette dernière, je n'ai qu'à faire :
String strMonPraram = getParameter( "StringParamName" );
et
DefaultFileItem dfiBackground = getFileItem( "FileUploadParamName" );
 
Un peu comme en PHP quoi

je comprend pas bien ... tout le traitement que tu fais c'est ce que fait le DiskFileUpload ...
 
ex d'utilisation unitaire :  
 

La seule différence que je vois c'est que ton code met les fichiers uploadés dans une map alors que le parseRequest les file dans une List ...
 
 
Ensuite dans la requête, libre à toi d'appeler le parseRequest si tu attend un upload de fichier ou alors de manipuler l'objet request normalement (getParameter) pour récupérer les parametres

Je vais voir ça demain...
Il est en effet tout a fait possible que je soit passé à coté de quelque chose si je comprend bien ce que tu écris

juste une remarque aussi : ton code va planté si dans une requête tu as 2 paramêtre du même nom (valeur multiple). Dans ce cas il faut appeler getParameterValues(String) qui retourne un tableau de String (les valeurs) plutot que getParameter(String) qui retourne juste la 1ere valeur.
Tu as aussi la méthode getParameterMap() qui fait exactement ce que fait la fin de ton code ...

en fait j'ai l'impresion que tu as utilisé l'objet DiskFileUpload comme l'objet FileUpload  
Le DiskFileUpload ajoute justement tout le mécanisme de sauvegarde disque des fichiers uploadés ...

Ok, je savais bien que je devait en parler à un connaisseur
M'enfin, c'est quand même loin d'être simple et clairement expliqué dans les docs, non ?

ben perso je connaissais pas cette API et j'ai compris rapidement ...
et c'est assez bien expliqué sur leur site : http://jakarta.apache.org/commons/ [...] using.html
 
Mais bon, c'est pas de ta faute : t'as été martirisé par du PHP quand tu étais petit

Ce que j'ai lu n'est pas très éloigné de ce que j'ai fais il me semble...

Non mais sur la fin, le code qu'ils montrent c'est si tu veux gérer les choses à la main, genre copier le fichier dans des répertoires différents, chnager le nom, etc ...
 
D'après ce que j'ai vu de ton code, ce que tu fais ne va pas plus loin que ce que fait le DiskFileUpload ...

Bon, on reprend depuis le début, c'est à dire mes besoins :
 
1- Dans les classes de traitements, je ne veux pas me poser la question du format de la requête HTTP.
2- J'ai besoin d'une méthode simple qui me retourne la valeur d'un champ de formulaire en fournissant son nom.
3- J'ai besoin d'une méthode simple qui me retourne un DefaultFileItem d'un champ de formulaire de type file en fournissant son nom.
 
Donc il faut :
1- Que je parse la requête avec la bonne méthode suivant son content type.
2- Que les paramettres de la requête, une fois cette dernière parsée, soient dans une HahsMap et non une simple liste, si je veux pourvoir y accéder directement par leurs noms.
 
Reste le problème des multivalués que je n'ai pas abordé pour le moment.
Toutefois, j'entrevoie un problème ( que je n'avais pas en PHP ) :
Par exemple, sur un <select multiple...> on se dit que ce serait sympa de récupérer une collection. Mais que se passera-t-il si l'utilisateur ne sélectionne qu'une seule option ?
Le même formulaire donnera quelque-fois un String, et d'autres fois une Collection de Strings... Pas impossible à gérer, mais pas cool

 
Ben non. Si tu fais un getParameters tu récuèreras un tableau de String dans tous les cas. S'il n'y a qu'une seule fois le paramètre dans la requète, ton tableau sera de longueur 1, c'est tout.

Ok, je te crois. J'ai pas essayé, mais je ne peux m'empécher de me demander : comment fait le parser pour savoir qu'il doit créer un tableau quand une seule valeur est envoyée ?
D'après mes expériences d'annalyse de requete HTTP, je ne vois pas bien comment c'est possible...
Quand la requête envoie :
TOTO=0&TOTO=4&TOTO=7&ACTION=GO
Je devine comment fait le parser pour décider que TOTO est un multivalué, mais s'il n'y a qu'une seule valeur ?

en interne, c'est une hashmap qui est stockée, qui associe de clé-String a des values-String[]
 
qd tu fais un getParameter(String s) ça te renvoie en fait map.get(s)[0]
 

c quoi la question?

 
De toute façon, la méthode est typée (comme tout en Java). Elle te rend un tableau de String, et pas autre chose. ça tu peux en être sur. Après, comment elle se démerde derrière, c'est pas franchemetn ton problème!

Ok, j'avais mal lu (getParameters au lieu de getParameter)...

 
Putain, mais quel bouley ce Dad !
 
Ok, j'ai un formulaire en "multipart/form-data".
Ce formulaire envoie aussi bien des fichiers que des champs normaux. Par exemple un <input type="texte" name="TOTO" value="test">
 
Donc coté java :

Et bien sûr param == null !
 
Est-ce que vous commencez à comprendre mon problème, ou est-ce que je suis un irreductible bouley ( pas impossible ça... )

nan mais je comprend bien ... tu veux une map à la place d'une List ... et là c'est clair que t'as pas le choix, il faut que tu te la créé à la mano.  
 
(remarque, je pense pas que le request.getParameter fonctionne dans le cas d'une requete multipart. Faut surement récupérer les paramêtres dans la List comme c'est indiqué sur le site)

comme dit benou, sauf que j'espere qu'il y moyen de recuperer qqchose comme une "MultiPartHttpServletRequest", qui implemente la meme interface que ServletRequest ! (c'est le cas avec le truc d'oreilly que j'avais mentionné)

pas dans le truc d'apache ...
mais ca se fait en 2 coups de cuillères à pot. (amis des proverbes à la con )

Ok, j'ai donc bien fait ce qu'il falait faire ( sauf utiliser le truc d'oreilly ).
A la fin de mon code, si le formulaire n'est pas "multipart", je recopie les params dans ma hasMap pour avoir un accès standard aux paramètres, indépendement du enctype du formulaire.
 
Reste les multivalués...
Le développeur sait bien sûr s'il attend un tableau ou pas. Il peut donc choisir entre getParameter ou getParameters.
Le problème, c'est que j'interviens avant le développeur, et que je n'ai pas de moyen à priori de savoir si le champs est une collection ou pas.
Une solution simple serait de traiter tous les paramètres non fichiers comme simples ET comme collections.
On aurait donc :
Une HashMap pour les fichiers.
Deux HasMap pour les paramètres. Une qui considère les paramètres comme simples,  et une autres qui les prends comme des collections.
C'est un peu du gâchi, mais çà doit marcher.
Reste à trouver l'équivalent du getParameters pour un multipart, ou regarder du coté d'oreilly...
 
Bon, je vais me sustenter, et je reviens

a mon avis dans ta hashmap tu dois uniquement stocker des String[]
et renvoyer un objet qui encapsule cette hashmap qui a 2 methodes  getParameter et getParameters. (la premiere ne renvoyant que le 1er element de l'array)

Arf, pas con du tout ça !
 
Autres choses à voir :
1- Si l'action d'un formulaire POST multipart contient aussi des paramètres (en GET donc), il ne faut pas les oublier. Conclusion, il faut gérer request.getParameterNames(); dans tous les cas, enfin il me semble...
 
2-Pour les multivalués dans un multipart, comme tout ce qu'on a est une List de DefaultFileItem, on est obligé de faire la détection sois même. Attention tout de même de ne pas mettre un champs de formulaire et un upload dans une collection sous prétexte qu'il ait le même nom
Blague à part, en fait comme tout les éléments sont des collections (ou des tableaux,...) dans les HashMaps, il suffit de rechercher dans cette dernière si on a déjà quelque-chose pour le nom. Ce qui pose un nouveau problème si quelqu'un pond une page HTML avec des params ( un en GET et un en POST "multipart" ) avec le même nom... M'enfin YAKA dire que ça n'arrivera pas

1/ pour le get, je vois pas pq tes parametres seraient gerés differement de ceux du post.

Je fait un test de ce que j'ai en tête, et je t'envoie le résultat (requête HTTP et ce que vois DiskFileUpload).

Donc, résultat des course, j'avais raison
 
D'abord, le HTML :

 
Ce qu'envoie le navigateur (merci FireFox 0.8 + Live HTTP Headers ) quand on sélectionne v2 et v8 dans la liste (y'a pas de file, mais c'est pas le propos...):

 
Le JSP (on ne peut plus basique):
 

 
Et maitenant le code java qui traite la request :

 
Et enfin le résultat :

 
On vois bien que ce qui est passé dans l'URL ( en GET donc ), n'est pas du tout traité par le upload.parseRequest( request ). Ce qui est tout à fait "normal" vu que c'est pas son boulot !
 
M'enfin, je tiens le bon bout, me reste plus qu'à paufiner mon parseur et les méthodes getParameter(s) d'ActionBean.
 
Merçi à tous de m'avoir supporté si longtemps, et à la prochaine pour les inévitables coups de gueule que Java ne manquera pas de me faire pousser    

d'un autre coté, je suis pas convaincu que c'est "standard" d'avoir des parametres "en post" et "en get" sur la meme requete..

Peut-être pas n'empèche que même s'il y a des chances qu'on n'utilise jamais un truc aussi crado, on ne peut pas jurer que ça ne soit jamais utilisé. Quelques fois, on est obligé d'utiliser un artifice de ce genre pour ne pas remettre en cause tout un édifice longement pensé, et ajouter au dernier moment la petite feature que veut le client.
De toute manière çà ne me coûte strictement rien de le faire donc y'a pas de raison de se priver.

le http le permet donc bon ...

ce que je dis c'est que je suis pas sur que ce soit dans la rfc

ouais, je suis pas allé vérifier ...  
mais si je devais parrier je dirais que c'est permis

ok
d'un autre coté ça me semble vraiment louche que le machin de jakarta permette pas de recuperer un truc qui implemente ServletRequest
(y'aurait pas ça dans un autre commons-* des fois?)

pas à ma connaissance ...

Py z'ètes que des menteurs !
c'est pas getParameters mais getParameterValues !
Py encore une autre remarque : le mélange GET dans l'url et le formulaire ne marche que si le form est en POST. En GET, les params de l'url sont écrasés par ceux du formulaire...
Bref c'est quand même à éviter, ce qui n'empèche pas de gérer le cas.

Arf, je viens de le voir. C'est el_gringo ( http://forum.hardware.fr/hardwaref [...] tm#t637151 ) qui m'a enduit d'erreur, que tout le monde à repris ensuite
Bon, py je vous aime bien moi, c'était juste un blague hein