Discussion :

[0nn2belle]

Bonjour à tous, je suis bien embêtée ! Je n'arrive pas à récupérer l'URL courante de ma page jsp principale.
Voici l'architecture de mon projet :
Une page index.jsp qui fait des include sur plusieurs modules (authentification, catégorie...).
Dans ces includes, par exemple authentification.jsp, j'ai un formulaire qui me redirige vers une servlet.
Dans cette servlet, je souhaite qu'à la fin de mon traitement je sois redirigée vers ma page qui contient tous mes includes (ici index.jsp).
En revanche, il est possible que je me retrouve dans une autre page comme categorie.jsp qui contient également ces includes.
Je cherche donc à savoir comment retourner sur cette dernière page ouverte qui contient tous les includes qui m'ont permis notamment de m'authentifier.

J'ai déjà essayé avec getHeader, mais il me retourne null quand j'exécute ma page index.jsp puis quand je navigue il me retourne la page précédente. Or, il faut que la servlet connaisse la page courante (celle qui contient les includes, ici index.jsp ou categorie.jsp) quand j'y fait appel

Un peu compliqué je sais

Merci d'avances pour vos réponses !

[jadey]

Tu risque de passser un moment avant de pouvoir t'en sortir. Je serais toi, j'investirai ce temps à regarder du côté de struts 1 qui répond aux questions liées à ce que tu envisages de faire assez facilement.
Il y'a un excellent tuto de serge tahé sur le sujet. Bonne chance.

[0nn2belle]

Bonsoir, merci de ta réponse, mais malheureusement je suis obligée d'utiliser les pages JSP...

[Lorantus]

JSP ? C'est une contrainte bien grande....
Un portlet, vous connaissez ? Uen techno. Java, pourtant si mal utilisé -je suis pas le premier à l'utiliser
Juste à développer les portlets, 1 par module, au moins. L'index.html sera géré par le conteneur de portlet.

[tchize_]

Tu risque de passser un moment avant de pouvoir t'en sortir. Je serais toi, j'investirai ce temps à regarder du côté de struts 1 qui répond aux questions liées à ce que tu envisages de faire assez facilement.
Il y'a un excellent tuto de serge tahé sur le sujet. Bonne chance.

houla, struts 1 pour un nouveau projet? Vous osez conseiller ça? Struts 1 a été remplacé par struts 2 depuis plusieurs années, il ne fait plus l'objet de maintenance et la dernière release date de 2008!

[Alain Defrance]

Salut.

Tu as une variable présente (et spécifié) :

Code :

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

req.getAttribute("javax.servlet.forward.request_uri")

Il existe aussi la version include

Par contre attention, nous on a eu des problèmes avec certains serveurs d'applications. En effet ca passe impec sur tomcat/jboss. Par conte jetty est un peu lourd. Ca reste à être fixé.

[OButterlin]

A moins de n'avoir rien compris au besoin, il me semble que tu cherches à savoir dans une servlet d'où tu viens.
Pourquoi ne pas inclure dans toutes tes pages un nom (unique) sous forme de champ caché pour les formulaires ou de paramètre d'url pour les liens qui te permettra de retrouver l'origine ?

[Alain Defrance]

A moins de n'avoir rien compris au besoin, il me semble que tu cherches à savoir dans une servlet d'où tu viens.
Pourquoi ne pas inclure dans toutes tes pages un nom (unique) sous forme de champ caché pour les formulaires ou de paramètre d'url pour les liens qui te permettra de retrouver l'origine ?

Certainement parce que ceci sous entends qu'il faudra gérer cette variable et que ca engendre du travail qui serait interessant de ne pas supporter.

[OButterlin]

Je suis d'accord, mais le referer n'est pas toujours renseigné hélas, la méthode "à l'ancienne" a le mérite de fonctionner partout.

[bilbonotry]

houla, struts 1 pour un nouveau projet? Vous osez conseiller ça? Struts 1 a été remplacé par struts 2 depuis plusieurs années, il ne fait plus l'objet de maintenance et la dernière release date de 2008!

Peut être parce que Struts 1 est éprouvé, stable, beaucoup plus facile à mettre en place que Struts 2 qui est bien pour un gros projet mais qui est une vraie usine à gaz.

PS : oui j'ai été traumatisé par la mise en place de Struts 2 et son framework de validation

[mattrixx]

je sais pas si je peux aider mais moi j'utilise cela pour retourné à la page précédente

request.getHeader("referer");

sous la forme d'un liens comme ceci :
<a href='<%=request.getHeader("referer")%>'>Recommencer</a>

[tchize_]

je ne suis pas d'accord:

struts 1 deviens aussi très vite une usine à gaz, vous avez des tonnes de classes et de fichiers à mettre en oeuvre pour faire le moindre formulaire
pour une application "simple", des framework standard comme JSF sont très faciles à mettre en oeuvre
démarrer une application sur un techno stable mais cliniquement morte, c'est foncer dans le mur au moindre soucis avec des technologies moderne (aucune garantie que ca marchera avec java 7, aucune garantie que ce sera compatible avec HTML5, etc)

C'est une chose de continuer avec malgré les risques parce qu'il donne satisfaction et qu'il serait trop cher de migrer l'application existante, ca en est une autre de démarrer un nouveau projet en lui faisant inutilement courir ce risque.

[bilbonotry]

Je comparais Struts 1 au 2. Il n'y a pas photo entre les deux en ce qui concerne les "tonnes de classes et de fichiers à mettre en oeuvre pour faire le moindre formulaire pour une application simple".
Après je ne dis pas, il vaut bien sûr mieux utiliser des frameworks pérennes comme JSF qui en plus est standard, mais il vaut encore mieux donner de vrais arguments pour ça.
Le "aucune garantie que ça marche.." est assez drôle, parce que les applications compilés en 1.4 ne marchent pas avec un jre 1.6 peut-être ? Concernant HTML 5, si Struts n'est plus "supporté", y a un paquet de sites qui ont du souci à se faire...

[tchize_]

Struts c'est du java 4, ce qui signifie déjà que vous perdez pour tout ce que vous y envoyez l'avantage des générique.

Et non, pour le passage de java 1.4 à 5, toutes les applciation n'ont pas migré correctement, certaines ont nécessité des ajustements et c'est le sens de mon argument, il n'y aura aucun ajustement de struts 1 pour supporter java 7. Ca marche tant mieux, mais c'est pas garanti.

On a ici des libriaries qui datent de java 1.4, le jour où on aura un bug dedans à corriger, on l'aura dans le baba, ces applications ne compilent pas sous java 5

Pour le HTML5, quand vous aurez un client à qui vous fournissez du struts 1 qui vous demande de mettre des info dans le champs comme on le fait si bien avec du html5, ou de faire un champ d'upload multiple, vous l'aurez aussi dans le baba.

C'est le sens de mon argumentation. Je n'ai jamais utilisé struts2, mais je sais que struts 1 pour l'avoir pas mal utiliser, c'est lourd à mettre en oeuvre et y a du xml dans tous les sens. Et un truc qui n'a plus subit une seule mise à jour depuis 2008, je m'inquiète inévitablement pour la réactivité en cas de nouveaux bug découvert.

Pour faire une petite appli vite fait, j'utiliserais plutot des outils comme JSF (quoi qu'un peu lourd) ou vaadin.

[bilbonotry]

Oui, on est bien d'accord sur les nouveautés qui ne seront pas supportées dans Struts 1 et qui peuvent être bloquantes.
Par contre en ce qui concerne les librairies 1.4, je ne comprends pas bien : n'y a-t-il pas un paramètre de javac permettant de spécifier la version de java à utiliser pour la compilation ? Du genre -source 1.4 ? Ou cette solution ne fonctionne-t-elle pas (on m'aurait menti) ? Je n'ai jamais testé.

[tchize_]

vous avez beau utiliser -source 1.4, vous continuez à utiliser l'api java 5 ou 6 derrière, donc tout changement de comportement pour lequel votre application n'est pas prête vous influencera inévitablement. De plus vous allez générer des tas de warning sur les mots clé qui n'en étaient pas en java 1.4