Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans le
message de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" <fabien.bergeret@asupprimer.laposte.net> a écrit dans le
message de news: 42e65a23$0$7835$626a14ce@news.free.fr...
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans le
message de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
Mathieu wrote:Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans
le
message de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).
Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Mathieu wrote:
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" <fabien.bergeret@asupprimer.laposte.net> a écrit dans
le
message de news: 42e65a23$0$7835$626a14ce@news.free.fr...
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).
Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Mathieu wrote:Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans
le
message de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).
Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Mathieu
"Fabien Bergeret" a écrit dans le
message de news: 42e692e1$0$7116$Mathieu wrote:Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans
lemessage de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacerles
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuventenvoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sontorientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
parune servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Mathieu
"Fabien Bergeret" <fabien.bergeret@asupprimer.laposte.net> a écrit dans le
message de news: 42e692e1$0$7116$636a15ce@news.free.fr...
Mathieu wrote:
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" <fabien.bergeret@asupprimer.laposte.net> a écrit dans
le
message de news: 42e65a23$0$7835$626a14ce@news.free.fr...
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacer
les
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).
Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?
Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?
Mathieu
"Fabien Bergeret" a écrit dans le
message de news: 42e692e1$0$7116$Mathieu wrote:Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?
Mathieu
"Fabien Bergeret" a écrit dans
lemessage de news: 42e65a23$0$7835$Stephane Zuckerman wrote:Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacerles
servlet . OUI ou NON ???
Je suis un peu perdu dans ce concept.
Les deux sont exécutées côté serveur.
De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).
Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuventenvoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sontorientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
parune servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.
Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM
(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.
Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
proceder de la sorte (l'approche est alors de créer une classe servlet
de base qui factorise le comportement communde toutes les servlets de
ton appli, et de l'etendre, pour creer une servlet pour chaque action
unitaire de ton appli).
Si l'on s'appuie sur un framework tel que struts, il existe une seule
servlet, mais qui n'a aucune valeur ajoutee d'un point de vue
traitement, et qui redistribue les appels vers des "actions" suivant un
fichier xml de mapping.
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
proceder de la sorte (l'approche est alors de créer une classe servlet
de base qui factorise le comportement communde toutes les servlets de
ton appli, et de l'etendre, pour creer une servlet pour chaque action
unitaire de ton appli).
Si l'on s'appuie sur un framework tel que struts, il existe une seule
servlet, mais qui n'a aucune valeur ajoutee d'un point de vue
traitement, et qui redistribue les appels vers des "actions" suivant un
fichier xml de mapping.
Dans une approche servlet/jsp pure, il est tres fortement deconseille de
proceder de la sorte (l'approche est alors de créer une classe servlet
de base qui factorise le comportement communde toutes les servlets de
ton appli, et de l'etendre, pour creer une servlet pour chaque action
unitaire de ton appli).
Si l'on s'appuie sur un framework tel que struts, il existe une seule
servlet, mais qui n'a aucune valeur ajoutee d'un point de vue
traitement, et qui redistribue les appels vers des "actions" suivant un
fichier xml de mapping.