Reprise du message précédent :

en effet certainement pas là puisque ce dont tu me parles est spécifique à l'http, alors qu'une ServletRequest ne l'est pas. (une HttpServletRequest l'est, par contre)
et puis en dehors de la javadoc, y'a des tutos, et ce sujet est certainement traité.
 

il y a des librairies tres bien écrites qui font ça pour toi
 

à mon sens, ne pas s'en servir comme point d'entrée mais juste comme un systeme de templates.
 
 

tu peux faire de la précompilation.
tu peux aussi faire des tests "unitaires" sur des jsp.
 

c'est sur que ça aide pas

HttpServletRequest hérite de ServletRequest !
getParameter n'est pas décrit dans HttpServletRequest...
 

Par exemple ( avec request qui est une HttpServletRequest ) :
 

Bref, ya surement quelqu'un qui a déjà fait la super méga géniale classe qui va bien pour gérer tous les cas, mais je ne l'ai pas trouvée. J'ai donc écrit la mienne. Pas la peine de dire que j'avais autre chose à faire
 

Yes, je ne vois pas ce que ça change... à partir du moment ou HttpServletRequest.setAttribute() prend un Object comme paramètre valeur...
T'es obligé de caster à tout bout de champs. C'est plus du tout de l'objet ça.
 

Bien sûr, c'est super pratique de simuler des HttpServletRequest.  Surtout avec de l'upload de fichiers. Combien de lignes de code pour faire des tests unitaires !
 
J'ai vraiement envie de laisser tomber les JSPs  et de faire une couche de présentation. Mais bon on ne me laissera pas faire

en plus de ce qu'a dit --, les formulaire multipart ne sont pas gérés par l'API de base des servlets, donc c'est logique que tu n'en trouves pas la doc ...
 
mais tu as raison, c'est un besoin très classique qu'ils auraient implémenter depuis un moment ... mais tu trouveras des tas de petites API qui font ca : http://www.google.fr/search?hl=fr& [...] vlet&meta=
 
et comme toujours, tant qu'à faire, autant prendre l'implémentation d'apache : http://jakarta.apache.org/commons/fileupload/

Si tu fais les choses proprement (avec la jstl, et autres tag libs), tu n'aurais pas de cast dans tous les sens ...
mais bon, c'est sûr que c'est plus contraignant et en même temps, se tromper de type de classe, c'est bizarre, logiquement tu sais ce que tu as mit dans ta request  ... personnelement, ca m'arrive jamais comme type d'erreur ...

Bref c'est galère, c'est tout ce que je dis.
 

C'est ce que j'ai fais : voir mon post
 
Mais c'est chiant à gérer.
Pour me simplifier la vie, j'ai donc une méthode d'une classe d'outils qui me retourne une HashMap qui contient soit des DefaultFileItem, soit des String. La méthode utilise soit le fileupload de jakarta, soit directement le getParameter de HttpServletRequest en fonction du getContentType de la request.
Ensuite, si c'est "multipart/form-data", il faut pour chaque champs se poser la question de savoir si c'est un champs de formulaire ou un fichier, et pour chaque fichier s'il est dans un fichiers temporaire ou en mémoire...
Bref, sur ce coup là, je trouve qu'on est obligé de réinventer la roue tout le temps. Sur un truc comme ça, PHP te facilite vraement la vie.

créez un topic, je suis interessé et ce sera plus accessible

je comprend pas ... logiquement, tu dois savoir le type de parametre que tu as en fonction de leur nom ... c'est toi qui l'as écrite la page HTML qui fait la requête ...

Oui, si je fais tout le bordel pour chaque page.  
Là je parle d'une méthode GENERIQUE qui est utilisé partout.
Elle retourne une hasMap de tout ce que contient le formulaire envoyé.
Ensuite, dans mon actionBean, bien sur que je sais de quoi il s'agit.
Bref, j'ai ajouté une couche qui fait que pour mes actionBeans, le type de formulaire untilisé est transparent. En gros comme en PHP

 
 
je pense que tu te compliques la vie tout seul

Pour un petit site avec 3 pages peut-être, mais pour un CMS, je ne pense pas être très exigeant !

je sais pas ce que c'est qu'un CMS, mais je pense que malgrès tout tu te compliques la vie ...
J'ai fait beaucoup d'appli web et j'ai jamais resenti le besoin de me faire un "truc générique". Je pense que tu as gardé des habitude de PHP et que tu es un peu perdu de pas les retrouver ... Mais je pense aussi que on ne code pas de la même façon une appli PHP et une appli web java ...

ContentManagementSysteme (pour le S je ne fais que presumer)

thx.
 
dady> après pour avoir un truc bien carré, y a toujours la possibilité d'utiliser un framework genre struts ou JSF ...

bon c'est pas bientôt fini le HS ?

C'est vrai que j'ai gardé des habitudes de PHP.
Quand c'est des bonnes habitudes, je suis un peu déçu de pas retrouver un truc equivalent dans J2EE.
Je ne vois pas trop pourquoi le programmeur doit se taper la décomposition de la requête reçue par le client c'est tout.
Ce que je veux est simple :
Le client envoie une requête HTTP:
L'HttpServletRequest propose une collection (ou plusieurs) qui contient tous les élément reçus, quelle que soit la méthode, histoire que le programmeur ne soit pas obligé d'aller fouiller dans 15 APIs pour retrouver ses petits.
En PHP, quelle que soit la requête reçue, tu as les collections suivantes :
$_GET
$_POST
$_SESSION
$_COOKIES
$_FILES
Que ton formulaire mélange GET et POST ou qu'il soit en "multipart/form-data", t'as pas à te poser la question. Et c'est pas plus mal, vu que tu as rarement (voire jamais) la nécessité de gérer ce genre de choses.
Pour les Fichiers uploadés, tout ce que t'as à faire, c'est les déplacer à leurs place définitive. Si tu ne le fais pas, ils sont automatiquement supprimés à la fin du script.
Bref, gérer un upload de fichier se fait en 2 lignes en PHP alors qu'avec java, ben j'essaye même pas de compter...
M'enfin, c'est du passé, j'ai plus le problème maintenant

Si

t'as exactement pareil avec la librairie COS par exemple.
et puis si t'as l'impression d'être emmerdé, dis toi bien que c'est surtout parce que tu es bcp moins limité..

http://forum.hardware.fr/hardwaref [...] -46149.htm

 
ils ont de ces noms de fonction à ralonge dans l'API Win32

Enregistrement de la nouvelle valeur dans la base

CLASS_GREVE

J'adore le controle timer

GUARD: You don't frighten us, English pig-dogs! Go and boil your
bottoms, sons of a silly person. I blow my nose at you,
so-called Arthur-king, you and all your silly English kaniggets.
Thppppt!
GALAHAD: What a strange person.
ARTHUR: Now look here, my good man!
GUARD: I don't want to talk to you no more, you empty headed
animal food trough water! I fart in your general direction! You
mother was a hamster and your father smelt of elderberries!
GALAHAD: Is there someone else up there we could talk to?
GUARD: No, now go away or I shall taunt you a second time-a!
 
 
(je fais les messages d'erreur de mon appli)

M.
Ducarme a trouvé un accord avec le receveur des contributions

EPSILONDATE

ViewSonic 19" - P95f+SB

subroutine polar(x, y, r, theta)
       
      double precision x, y, r, theta
       
      double precision pi
      double precision temp
       
      pi=4*datan(1d0)
       
      r=dsqrt(x**2+y**2)
       
      temp=datan(y/x)
      if (x.gt.0d0) then
        theta=temp
      else if (x.lt.0d0) then
        theta=-temp
      else if (x.eq.0d0) then
        if (y.ge.0d0) then
          theta=pi/2
        else
          theta=-pi/2
        endif
      endif
       
      return
      end

\newpage
  \subsection*{Copie d'écran}
  \begin{center}
    \includegraphics[width=15cm]{banque.eps}

MessageFilter ( )

enorme: http://www.google.com/search?q=jbossql+functions

pas encore développé, en cours}

qu'est ce qui est fort ? que la norme EJB soient tellement plein de trou que tous les serveurs d'application doivent y aller de leurs ajouts propriétaires pour la rendre utilisable ?  
 
edit : oups, on est pas sur blabla  

     memcpy

(define epsilon 0.0001)
(define (cube x) (* x x x))

non, le 6e lien dans google.

Google part en vrille q