Discussion :

[El Saigneur]

Bonjour

Je rencontre des difficultés avec le composant fileUpload de RichFaces. Le composant est placé au sein d'un formulaire comportant d'autres inputs. Je configure le fileUploadListener de façon à ce qu'une méthode d'un backing bean soit executée lorsqu'un fichier est uploadé. Le problème c'est que dans cette méthode, les autres input du formulaire sont null. Il semblerait que le composant fileUpload ne submite que le file mais pas les autres input du formulaire. Or j'ai aussi besoin de ces inputs.

Voici le code de ma page :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
<h:form>
...
<tr>
	<td colspan="4" align="center">
		<rich:fileUpload
		addControlLabel="Add the desired file ..."
		fileUploadListener="#{monManagedBean.onUploadCompleted}"
		maxFilesQuantity="1" acceptedTypes="csv"
		/>
        </td>
 
	<td align="right">
		<h:outputLabel id="autreInputLabel" value="Autre input" />
	</td>
	<td align="left">
		<h:inputText id="autreInput" value="#{monManagedBean.monAutreParam}" />
	</td>
</tr>
...
</h:form>

Le code du backing bean :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 
private String monAutreParam;
// getters et setters ...
 
public void onUploadCompleted(final UploadEvent uploadEvent) {
	final UploadItem uploadItem = uploadEvent.getUploadItem();
	final File file = uploadItem.getFile();
        // ...  code où j'ai besoin de monAutreParam, mais à ce niveau il est toujours null
}

Voilà !

Donc comment faire pour récupérer côté serveur, dans une méthode de mon backing bean, à la fois le file uploadé et tous les autres params du formulaire ?

Merci d'avance pour votre aide

[Sniper37]

essaye avec

Code :

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

<a4j:support event="onuploadcomplete" action="#{bean.action}" reRender="composant"  />

[El Saigneur]

Merci pour ta réponse Sniper37.

Le problème c'est que dans la méthode du bean spécifiée par l'attribut [action] du composant [a4j:support], je n'ai plus accès au fichier uploadé. En effet, une méthode d'action sur le managed bean ne prend pas de paramètre et je n'ai donc plus le UploadEvent qui me permettait d'avoir le fichier uploadé avec la méthode spécifiée par le [fileUploadListener].
Donc, plutôt que d'utiliser le [fileUploadListener], j'utilise [uploadData] qui me permet de stocker dans mon managed bean la liste des fichiers uploadés. Mais là, même soucis. Dans la méthode du backing bean, ma liste de UploadItem est null. Et si je l'initialise dans mon constructeur pour éviter un NullPointerException, elle est vide. Bref j'ai perdu mon fichier uploadé.
Cela semble logique étant donné que le fichier est uploadé dans un premier temps via une requête ajax et que l'appel à ma méthode se fait dans un second temps (sur l'évènement onuploadcomplete) par une autre requête. Le bean a dès lors perdu le fichier uploadé dans sa liste de UploadItem (le scope du managed bean est [request]).

Ci-dessous mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
<h:form>
...
<tr>
	<td colspan="4" align="center">
		<rich:fileUpload
		addControlLabel="Add the desired file ..."
                uploadData="#{monManagedBean.uploadedFiles}"
		maxFilesQuantity="1" acceptedTypes="csv">
		    <a4j:support event="onuploadcomplete" action="#{monManagedBean.process}" />
		</rich:fileUpload>
        </td>
 
	<td align="right">
		<h:outputLabel id="autreInputLabel" value="Autre input" />
	</td>
	<td align="left">
		<h:inputText id="autreInput" value="#{monManagedBean.monAutreParam}" />
	</td>
</tr>
...
</h:form>

et celui du managed bean

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
private List<UploadItem> uploadedFiles;
 
private String monAutreParam;
// getters et setters ...
 
 
public String process(){
    LOGGER.debug("monAutreParam = " + this.monAutreParam);
    LOGGER.debug("file uploaded size = " + this.uploadedFiles.size());
    // ici this.uploadedFiles == null si je ne l'ai pas initialisée dans mon constrcteur
    // Ou this.uploadedFiles.size() == 0, si je l'ai initialisée
    return null;
}

Je pourrais remettre le fileUploadListener (qui lui reçoit bien le fichier) et enregistrer temporairement mon fichier uploadé à un endroit connu pour pouvoir le rattraper lors de la seconde requête qui soumet le reste du formulaire. Mais tout ceci serait bien lourd.

Cela est assez énervant car avec une bonne vieille Servlet à l'ancienne et un <input type="file" ... > il n'y avait aucun problème. Certes on avait pas un composant qui fait de l'ajax et qui a un joli look avec progress bar et tout ça ; mais au moins c'était fonctionnel. Pour ma part, il est vraisemblable que je n'utilise peut-être pas ce composant comme il faut. Mais la doc est pauvre. J'ai lu en long en large et en travers la doc de RichFaces sur ce composant, les issues JIRA de RichFaces (j'ai même essayé les fonctions javascript beforeSubmit et submitForm) et rien n'y fait. C'est quand même décevant qu'un nouveau framework n'apporte pas de façon aisée ce qui est possible de faire facilement avec les technos sous-jacentes (Servlet).

Bref. Comment faire pour que lors de la première requête ajax (lancée lorsque j'appuie sur le bouton [Upload] du composant RichFaces fileUpload) le fichier mais également les autres request paramaters de mon form soient transmis ?

Merci

[El Saigneur]

Ce qui est dingue en plus c'est que si je fais appel à cette petite méthode dans le code de onUploadCompleted (cf. premier message de cette discussion) :

Code :

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

1
2
3
4
5
6
7
 
	public static void printRequestParameters() {
		final Map<String, String> params = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap();
		for (final String paramName : params.keySet()) {
			LOGGER.info(paramName + " => " + params.get(paramName));
		}
	}

et bien je constate que les params de mon form sont bien postés.
Pourquoi diable ne sont-ils donc pas settés dans les attributs de mon managed bean ?!

Je vais les attraper à la main sinon comme je l'aurais fait dans une Servlet avec les HttpRequestParameters. Mais ce serait quand même dommage. Si j'utilise JSF c'est pour éviter de faire ça !

[Sniper37]

ton bean est en request ou session??

Ce n'est pas normal que al liste des uploadItem soit null à la fin de l'upload,
si ton bean est en request, lors de la requete ajax les paramètres sont bien envoyés, mas, ne seront sauvegardé que pour cette requete;

[El Saigneur]

Mon bean est en scope request.
Quand tu dis :

mas, ne seront sauvegardé que pour cette requete;

"cette requete" correspond à quoi ? La requête ajax qui part quand je clique sur le bouton Upload ou la requête qui part sur l'évènement onuplodcomplete ?

Pour résumé voici comment je comprends le fonctionnement :

A - Si je fais avec le fileUploadListener="#{monManagedBean.onUploadCompleted}"

1) une requête HTTP part quand je clique sur le bouton Upload. Cette requête possède bien tous les request parameters mais JSF ne me les sette pas dans les attributs du bean. Je n'ai accès qu'à l'UploadEvent passé en paramètre de la méthode onUploadCompleted.

Pourquoi mes attributs ne sont pas settés alors qu'il sont présents dans la requête HTTP ?


B - Si je fais avec uploadData="#{monManagedBean.uploadedFiles}", que je garde mon fileUploadListener et que j'ajoute <a4j:support event="onuploadcomplete" action="#{monManagedBean.process}" />

1) Idem. Une requête HTTP part quand je clique sur le bouton Upload. La méthode onUploadCompleted est appelée. Dans cette méthode je constate que ma List<UploadItem> uploadedFiles est bien remplie avec le fichier uploadé. Ce fichier correspond également au fichier que j'obtiens avec UploadEvent passé en paramètre de ma méthode onUploadCompleted ( final UploadItem uploadItem = uploadEvent.getUploadItem(); ).
Par contre, les attributs de mon bean correspondant aux autres request parameters sont toujours null.

2) Une seconde requête HTTP se lance sur l'évènement onuploadcomplete. Le bean étant en scope request il est re-instancié. La List<UploadItem> uploadedFiles est donc vide. La méthode process est appelée. Ici les autres request parameters du form sont disponibles. Hourra ! Mais le file uploadé ne l'est plus. Désespoir !


Es-tu OK avec cette analyse ? Sinon je te remercie par avance de m'indiquer où je foire.

Merci encore

[Sniper37]

quand tu fais un upload d'un fichier, ya une requete ajax envoyé au serveur,

si tu utilise a4j:support, c'est une autre requete ajax, lorsque tu envoie le formulaire à la suite de tout ça, c'est une autre requete, les requêtes suivent le même cycle de vie JSF que ce soit une requete ajax ou une requête normale.
donc, le setter est fait la première fois et le bean est réinitialisé à chaque requete.
donc, pour résoudre le problème, il faut soit mettre le bean en session, soit utiliser a4j:keepAlive qui permet de garder le bean en vie pendant une période donnée.

[El Saigneur]

Désolé mais il est hors de question de polluer la session HTTP pour palier aux lacunes de l'outil. La RAM allouée à mon JBoss n'est pas infinie.

Il est vraiment aberrant d'en arriver à mettre des beans en session alors que tout est dispo dans la HttpServletRequest sous-jacente !

A l'intérieur de la méthode spécifiée par le fileUploadListener, je vais donc attraper les params dans la HttpServletRequest comme dans une bonne vieille Servlet. Au risque de passer pour un rétrograde, je pense que j'ai raison.

Merci pour ton implication sur mon problème. Et je suis vraiment déçu de JSF. Cela permet de faire des trucs vraiment sympa style Swing pour le web, ajouter de la richesse avec des librairies de composant style RichFaces mais il y a des trucs vraiment rédhibitoires. Le sujet dont on vient de parler, mais aussi des appels intempestifs aux getters et setters pour satisfaire les différents cycle du process JSF (ValueChange, etc...), l'incompatibilité entre les différents navigateurs (faut voir la tronche du TogglePanel sur IE 7 !!!), etc.

Bref. Je pense fortement à passer à Flex pour faire de la RIA lors des prochains projets de mon équipe. Facilité de développement de la GUI, communication avec BlazeDS, compatibilité assuré sur tous les navigateurs car s'exécutant dans le Flash Player, fonctionnalité très riches pour faire des graphiques (camemberts, histogrammes, etc.).

A +

Je laisse ce post ouvert au cas où quelqu'un me trouverait une solution pour faire marcher le rich:fileUpload en postant les autres params du form et en laissant le bean en scope request.

Merci encore

[Sniper37]

Il y'a des choses qui sont liés aux protocoles HTTP, donc, rien à voir avec JSF.

tu peux récupérer les valeurs de ton formulaires dans le listener, mais, si l'utilisateur commence à faire le upload avant de remplir les autres éléments, la liste des uploadItems doit rester sauvegardé quelque part..
c'est pour cela que tu peux utiliser a4j:keepAlive, qui garde le bean pendant les requêtes ajax par exemple..

Enfin, je ne penses pas que mettre un objet en session le temps de la conversation client/serveur pollue le serveur.

[El Saigneur]

Si l'utilisateur ne remplit pas les autres champs du form il se prendra une erreur. Ceci est bien normal, on ne soumet pas un form sans avoir rempli tout ce qui était nécessaire.

Ensuite quand tu dis qu'il y a des choses qui sont liés au protocoles HTTP, je suis d'accord que cela implique certaines limitations. Mais ici ce n'est pas la faute du protocole HTTP. La preuve j'ai mes request parameters dans la HttpServlerRequest mais c'est juste JSF qui ne me permet pas d'y accéder.

D'autre part quand tu dis que mettre un bean en session le temps d'une conversation ce n'est pas si préjudiciable, je ne te suis pas. Si tu multiplies cela par le nombre potentiel d'utilisateurs simultanés ... Aïe ! Puis au delà de ça, c'est une question de principe, je vais pas mettre des choses en session alors que j'ai tout ce qu'il me faut dans la HttpServletRequest sous-jacente.
Mettre des choses en session, c'est bon quand tu as une conversation longue sur plusieurs pages, style un panier sur un site de e-commerce ou pour le Managed Bean qui stocke les infos de l'utilisateur. Là tu ne peux pas faire autrement et c'est à ça que sert une session. Mais ce n'est certainement pas une chose à faire dans le cas qui nous concerne ici. Tu dois me trouver un peu psychorigide, mais ça va à l'encontre de tout ce qu'on m'a appris sur la programmation Web.

Même avec le a4j:keepAlive, je ne comprends pas pourquoi on devrait faire plusieurs aller-retour client / serveur alors qu'on a tout ce qu'il faut dans la seule première requête.

[Sniper37]

Je te rappelle que lorsque tu fais un upload par exemple, c'est une requete, certes une requete ajax, mais, une requete quand même, c'est un aller-retour au serveur mais asynchrone.
la seconde fois que tu souhaites envoyer une requete par le bias d'un commandButton ou a4j:support, c'est une autre requete, donc, les informations contenues dans la première requête ne seront pas disponibles dans la seconde requete.
JSF n'empêche jamais l'accès à une variable en request, la requete JSF suit un cyle qu'il est nécessaire de saisir.

[El Saigneur]

Justement, la seconde requête dont tu parles, je ne la fais pas. Relis mes posts précédents et tu comprendras.

Je récapitule. Voici le code :

Code :

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

1
2
3
4
5
 
<rich:fileUpload
addControlLabel="Add Samples upload file ..."
fileUploadListener="#{bean.onUploadCompleted}"
onuploadcomplete="window.location='#{facesContext.externalContext.requestContextPath}/autrePage.jsf';"/>

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public void onUploadCompleted(final UploadEvent uploadEvent) {
    // Ici j'attrape la valeur de mon autre param en allant dans la HttpServletRequest
    final String monAutreParamValue = super.getRequestParameterValue("form:autreInput");
 
// ici j'ai mon fichier uploadé		
final UploadItem uploadItem = uploadEvent.getUploadItem();
 
// et là j'appelle mon service Spring qui va bien avec mon java.io.File et mon autre param et la vie est belle
...
 
}

Il n'y a qu'une requête HTTP donc. N'est-ce pas ?

Après un petit code Javascript se lance sur l'évènement onuploadcomplete et me redirige vers une page qui me convient.

A +

[Sniper37]

ok,
je ne sais pas si le uploadListener fonctionne comme actionListener,
si les valeurs ne sont pas setter, essaye de les récupérer à partir des UIComponent, que tu peux récupérer par leur id ou dans le listener avec l'événement.
Si cela ne fonctionne pas, l'utilisation de a4j:support doit marcher.

--- Sinon je viens de voir qu'il existe une fonction javascript submitForm() utilisable avec fileupload, tu peux la tester dans onfileuploadcomplete

Code :

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

#{'fileUploadId'}.component.submitForm()

[Malone]

Bonjour,

je remonte ce sujet car je rencontre le même problème.
Donc pour résumer:

-Un managed bean (categorieAction) , en scope request.
-Dans ce managed bean, en propriété, une classe pour la gestion des uploads (uploadManager) que le compo richfaces rich:fileUpload utilise.


J'ai beau mettre une balise keepAlive, le managed bean est instancié à chaque upload.

la partie de la vue relative à l'upload (rien d'incroyable, quasi du copier coller du live demo richFaces):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
<a4j:keepAlive beanName="categorieAction" />
[...]
<rich:panel header="image">
		<h:panelGrid columns="2" columnClasses="top,top">
			<rich:fileUpload 
				fileUploadListener="#{categorieAction.uploadManager.listener}"
				maxFilesQuantity="1" id="upload" immediateUpload="true"
				acceptedTypes="jpg, gif, png, bmp" allowFlash="true"
				listHeight="60px">
				<a4j:support event="onuploadcomplete" reRender="info" />
			</rich:fileUpload>
			<br />
			<h:panelGroup id="info">
 
 
				<rich:panel bodyClass="info">
 
					<f:facet name="header">
						<h:outputText value="Information fichiers" />
					</f:facet>
					<h:outputText value="Aucun fichier envoye"
						rendered="#{categorieAction.uploadManager.size==0}" />
					<rich:dataGrid columns="1"
						value="#{categorieAction.uploadManager.files}" var="file"
						rowKeyVar="row">
						<rich:panel bodyClass="rich-laguna-panel-no-header">
							<h:panelGrid columns="2">
								<a4j:mediaOutput element="img" mimeType="image/jpeg"
									session="true"
									createContent="#{categorieAction.uploadManager.paint}"
									value="#{row}" style="width:100px; height:100px;"
									cacheable="false" id="imagePreview">
									<f:param value="#{categorieAction.uploadManager.timeStamp}"
										name="time" />
								</a4j:mediaOutput>
								<h:panelGrid columns="2">
									<h:outputText value="File Name:" />
									<h:outputText value="#{file.nom}" />
									<h:outputText value="File Length(bytes):" />
									<h:outputText value="#{file.taille}" />
								</h:panelGrid>
							</h:panelGrid>
						</rich:panel>
					</rich:dataGrid>
				</rich:panel>
				<rich:spacer height="3" />
				<a4j:commandButton
					action="#{categorieAction.uploadManager.clearUploadData}"
					reRender="info, upload" value="Supprimer les fichiers"
					rendered="#{categorieAction.uploadManager.size>0}" />
 
			</h:panelGroup>
 
		</h:panelGrid>
	</rich:panel>

[sir_gcc]

Je remonte le sujet au cas où quelqu'un aurait trouvé une solution.
J'ai regardé un peu ce que a4j propose mais je ne vois rien qui puisse faire que lors du passage dans la méthode listener (au moment de l'upload) les autres champs du formulaire soient postés.

La solution qui consiste à aller lire dans la request les valeurs des autres champs fonctionne bien, mais effectivement c'est dommage d'en arriver là.

[El Saigneur]

C'est marrant de voir resurgir ce post presque 2 ans après et de voir que le problème existe toujours. Merci, ça me rassure. J'ai moins l'impression d'être une buse.
Perso, à cause de moult cas comme celui-là rencontrés en utilisant JSF, j'ai abandonné cette techno depuis un moment. Je suis passé à Spring 3 MVC dès que Spring 3 est sorti. Le fonctionnement est bien plus logique et beaucoup moins lourd et obscur. Pour le richesse de l'interface j'utilise jQuery et je vous garanti que je suis très heureux comme ça. Cette expérience de quelques années sur JSF ne m'aura pas convaincu du tout.