Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à
l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce
traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial
en appuyant sur un bouton "Précédant". Le code JSP permettant cela est
ci-dessous:
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial en appuyant sur un bouton "Précédant". Le code JSP permettant cela est ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas dans le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait reveler quelque chose. J'utilise toujours le chemin complet dans mes "action='http://server:port/foo/bar'", ce qui fait que le parsing est toujours le meme.
-- JSC
Patrick Gelin wrote:
Bonjour,
Je fait une application WEB avec TOMCAT celon une architecture MVC. Je
rencontre un problème dans le système de navigation...
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à
l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce
traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial
en appuyant sur un bouton "Précédant". Le code JSP permettant cela est
ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas dans
le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait
reveler quelque chose.
J'utilise toujours le chemin complet dans mes
"action='http://server:port/foo/bar'", ce qui fait que le parsing est
toujours le meme.
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial en appuyant sur un bouton "Précédant". Le code JSP permettant cela est ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas dans le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait reveler quelque chose. J'utilise toujours le chemin complet dans mes "action='http://server:port/foo/bar'", ce qui fait que le parsing est toujours le meme.
-- JSC
Patrick Gelin
JScoobyCed wrote:
Patrick Gelin wrote:
Bonjour,
Je fait une application WEB avec TOMCAT celon une architecture MVC. Je rencontre un problème dans le système de navigation...
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial en appuyant sur un bouton "Précédant". Le code JSP permettant cela est ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas dans le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait reveler quelque chose. J'utilise toujours le chemin complet dans mes "action='http://server:port/foo/bar'", ce qui fait que le parsing est toujours le meme.
try{ String name = arg0.getPathInfo(); name = name.substring(1);
if ("NewsFormView".equals(name)) { ...
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); } } catch(Exception e){ log("Exception in ElmtCtrl.doGet()"); dispatcher = context.getNamedDispatcher("ErrorView"); } finally { dispatcher.forward(arg0, arg1); }
et cela est la même chose pour doPost qui commence de la même manière...
Ce qu'il me faudrait comprendre c'est quel est la racine du chemin relatif. Il semble qu'apres un accès dans une servlet ce soit la servlette elle même... Mais alors comment traiter le cas de la page d'accueil qui peut être accédée itnitiallement directement depuis l'extérieur, donc avec une racine qui est le répertoire racine de l'application mais aussi depuis d'autres servlettes, et dans ce cas la racine est la servlette source?
A+ --
JScoobyCed wrote:
Patrick Gelin wrote:
Bonjour,
Je fait une application WEB avec TOMCAT celon une architecture MVC. Je
rencontre un problème dans le système de navigation...
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel
à l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce
traitement l'utilisateur accède à une JSP de prévisualisation à
l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire
initial en appuyant sur un bouton "Précédant". Le code JSP permettant
cela est ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas
dans le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait
reveler quelque chose.
J'utilise toujours le chemin complet dans mes
"action='http://server:port/foo/bar'", ce qui fait que le parsing est
toujours le meme.
try{
String name = arg0.getPathInfo();
name = name.substring(1);
if ("NewsFormView".equals(name)) {
...
dispatcher = context.getNamedDispatcher(name);
if (dispatcher == null){
throw (new Exception());
}
} catch(Exception e){
log("Exception in ElmtCtrl.doGet()");
dispatcher = context.getNamedDispatcher("ErrorView");
} finally {
dispatcher.forward(arg0, arg1);
}
et cela est la même chose pour doPost qui commence de la même manière...
Ce qu'il me faudrait comprendre c'est quel est la racine du chemin relatif.
Il semble qu'apres un accès dans une servlet ce soit la servlette elle
même... Mais alors comment traiter le cas de la page d'accueil qui peut
être accédée itnitiallement directement depuis l'extérieur, donc avec une
racine qui est le répertoire racine de l'application mais aussi depuis
d'autres servlettes, et dans ce cas la racine est la servlette source?
Le submit envoie le contenu à la servlet ElmtCtrl, dans laquelle l'appel à l'API getPathInfo retourne /NewsFormView, et c'est correct. Après ce traitement l'utilisateur accède à une JSP de prévisualisation à l`adresse:
Dans cette prévisualisation l'utilisateur peut revenir au formulaire initial en appuyant sur un bouton "Précédant". Le code JSP permettant cela est ci-dessous:
Le problème est qu'il y a deux fois ElmtCtrl dans ce second cas et pas dans le premier...
Quelqu'un peut il m'expliquer pourquoi?
Merci pour votre aide.
Cela depend du code qui est dans votre servlet. Un bout de code pourrait reveler quelque chose. J'utilise toujours le chemin complet dans mes "action='http://server:port/foo/bar'", ce qui fait que le parsing est toujours le meme.
try{ String name = arg0.getPathInfo(); name = name.substring(1);
if ("NewsFormView".equals(name)) { ...
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); } } catch(Exception e){ log("Exception in ElmtCtrl.doGet()"); dispatcher = context.getNamedDispatcher("ErrorView"); } finally { dispatcher.forward(arg0, arg1); }
et cela est la même chose pour doPost qui commence de la même manière...
Ce qu'il me faudrait comprendre c'est quel est la racine du chemin relatif. Il semble qu'apres un accès dans une servlet ce soit la servlette elle même... Mais alors comment traiter le cas de la page d'accueil qui peut être accédée itnitiallement directement depuis l'extérieur, donc avec une racine qui est le répertoire racine de l'application mais aussi depuis d'autres servlettes, et dans ce cas la racine est la servlette source?
A+ --
JScoobyCed
Patrick Gelin wrote:
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); }
Dans le ServletContext.getNamedDispatcher(String), cela return le dispatcher qui correspond a ce qui est configure (par la console d'administration si elle existe dans le serveur d'application, ou dans le descripteur de deploiement). Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut etre que la solution est la. C'est tout ce que je vois pour le moment.
-- JSC
Patrick Gelin wrote:
dispatcher = context.getNamedDispatcher(name);
if (dispatcher == null){
throw (new Exception());
}
Dans le ServletContext.getNamedDispatcher(String), cela return le
dispatcher qui correspond a ce qui est configure (par la console
d'administration si elle existe dans le serveur d'application, ou dans
le descripteur de deploiement).
Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut
etre que la solution est la.
C'est tout ce que je vois pour le moment.
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); }
Dans le ServletContext.getNamedDispatcher(String), cela return le dispatcher qui correspond a ce qui est configure (par la console d'administration si elle existe dans le serveur d'application, ou dans le descripteur de deploiement). Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut etre que la solution est la. C'est tout ce que je vois pour le moment.
-- JSC
Patrick Gelin
JScoobyCed wrote:
Patrick Gelin wrote:
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); }
Dans le ServletContext.getNamedDispatcher(String), cela return le dispatcher qui correspond a ce qui est configure (par la console d'administration si elle existe dans le serveur d'application, ou dans le descripteur de deploiement). Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut etre que la solution est la. C'est tout ce que je vois pour le moment.
-- JSC C'est ce que je pense aussi mais je ne vois pas le problème. Mon descripteur
Lorsque je demande NewsFormView j'obtiens url_base/NewsFermView.jsp. Le problème c'est que la base change celon l'origine de la requête... parfois c'est:
http://localhost:8080/webapp_newsevent
et d'autres fois c'est:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Alors que faut il modifier pour que cela ne pose plus de problème? --
JScoobyCed wrote:
Patrick Gelin wrote:
dispatcher = context.getNamedDispatcher(name);
if (dispatcher == null){
throw (new Exception());
}
Dans le ServletContext.getNamedDispatcher(String), cela return le
dispatcher qui correspond a ce qui est configure (par la console
d'administration si elle existe dans le serveur d'application, ou dans
le descripteur de deploiement).
Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut
etre que la solution est la.
C'est tout ce que je vois pour le moment.
--
JSC
C'est ce que je pense aussi mais je ne vois pas le problème. Mon descripteur
Lorsque je demande NewsFormView j'obtiens url_base/NewsFermView.jsp. Le
problème c'est que la base change celon l'origine de la requête... parfois
c'est:
http://localhost:8080/webapp_newsevent
et d'autres fois c'est:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Alors que faut il modifier pour que cela ne pose plus de problème?
--
dispatcher = context.getNamedDispatcher(name); if (dispatcher == null){ throw (new Exception()); }
Dans le ServletContext.getNamedDispatcher(String), cela return le dispatcher qui correspond a ce qui est configure (par la console d'administration si elle existe dans le serveur d'application, ou dans le descripteur de deploiement). Si vous utilisez le web.xml pour declarer vos JSPs et Servlets, peut etre que la solution est la. C'est tout ce que je vois pour le moment.
-- JSC C'est ce que je pense aussi mais je ne vois pas le problème. Mon descripteur
Lorsque je demande NewsFormView j'obtiens url_base/NewsFermView.jsp. Le problème c'est que la base change celon l'origine de la requête... parfois c'est:
http://localhost:8080/webapp_newsevent
et d'autres fois c'est:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Alors que faut il modifier pour que cela ne pose plus de problème? --
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser, car il ne peut faire la distinction entre servlet et repertoire pour "ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL
de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser,
car il ne peut faire la distinction entre servlet et repertoire pour
"ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser, car il ne peut faire la distinction entre servlet et repertoire pour "ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser, car il ne peut faire la distinction entre servlet et repertoire pour "ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
sur ma page d'acceuil, mais cette fois l'url de base change sa valeur pour:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Il semble donc que l'url de base n'est pas été affectée par le GET sinon le <welcome-file>, mais par le POST sinon le <servlet-mapping> ...
il faut absolument que je trouve comment accéder à la page d'acceuil avec toujours le même chemin de base, sinon mon action de formulaire ne fonctionnera qu'une fois sur deux...
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL
de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser,
car il ne peut faire la distinction entre servlet et repertoire pour
"ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
sur ma page d'acceuil, mais cette fois l'url de base change sa valeur pour:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Il semble donc que l'url de base n'est pas été affectée par le GET sinon le
<welcome-file>, mais par le POST sinon le <servlet-mapping> ...
il faut absolument que je trouve comment accéder à la page d'acceuil avec
toujours le même chemin de base, sinon mon action de formulaire ne
fonctionnera qu'une fois sur deux...
Le <welcome-file> repond ElmtCtrl/NewsFormView, qui est ajoute a l'URL de base: http://localhost:8080/webapp_newsevent
Du coup, comme vous le precisez, l'URL de base devient (pour le browser, car il ne peut faire la distinction entre servlet et repertoire pour "ElmtCtrl") :
http://localhost:8080/webapp_newsevent/ElmtCtrl
Donc je pense qu'il suffit de retirer "ElmtCtrl" du cahmp 'action':
sur ma page d'acceuil, mais cette fois l'url de base change sa valeur pour:
http://localhost:8080/webapp_newsevent/ElmtCtrl
Il semble donc que l'url de base n'est pas été affectée par le GET sinon le <welcome-file>, mais par le POST sinon le <servlet-mapping> ...
il faut absolument que je trouve comment accéder à la page d'acceuil avec toujours le même chemin de base, sinon mon action de formulaire ne fonctionnera qu'une fois sur deux...