Discussion :

[Yonito]

Bonjour,

J'ai décidé de m'interesser à ce nouveau framework qu'est AngularJS mais j'aurai certaines questions sur la maniére dont sont envoyées les informations du serveur à la vue.

Je n'ai pas beaucoup de connaissance à ce niveau la hormis l'architecture que nous utilisons la ou je boss qui est je pense assez vieille. En effet, nous procédons comme suit : La servlet appelle directement la JSP qui elle contient du code Java qui fait appels au differentes classes bean puis construit un XML qui est envoyé à un fichier XSL pour générer une page HTML. La séparation des differentes couches est donc differentes que ce que je peux lire sur internet c'est à dire que la servlet fait appel au bean puis appelle la JSP qui utilise ses propres balises pour afficher le HTML dynamique. (J'ai souvent lu qu'une JSP ne doit en effet pas contenir de code JAVA).

Mes questions sont les suivantes :

1. Est ce que Angular vient remplacer la technologie JSP ?
2. Fait on toujours appelle depuis la servlet à des pages JSP qui contiendraient le code AngularJS ou bien fait on appelle directement à une page HTML avec du code AngularJS ?
2a. Si on fait toujours appelle à une page JSP, l'utilisation d'Angular vient elle remplacer les differents tag JSP et donc le fichier JSP ne serait donc qu'en réalité ni plus ni moins qu'un fichier html avec une extension JSP ?
3. Le rattachement des données qui formeront le contenue de la view est il passé en parametre au meme moment de l'appel de la page html/jsp ou bien le fichier html/jsp est chargé "vide" et c'est ce dernier qui une fois chargé fait des appels asynchrone pour recuperer les informations à afficher ? (j'espere avoir été clair)

C'est suffisant pour le moment. Merci de m'éclairer sur ce sujet.

Cordialement,

[eulbobo]

1. Est ce que Angular vient remplacer la technologie JSP ?
2. Fait on toujours appelle depuis la servlet à des pages JSP qui contiendraient le code AngularJS ou bien fait on appelle directement à une page HTML avec du code AngularJS ?
2a. Si on fait toujours appelle à une page JSP, l'utilisation d'Angular vient elle remplacer les differents tag JSP et donc le fichier JSP ne serait donc qu'en réalité ni plus ni moins qu'un fichier html avec une extension JSP ?
3. Le rattachement des données qui formeront le contenue de la view est il passé en parametre au meme moment de l'appel de la page html/jsp ou bien le fichier html/jsp est chargé "vide" et c'est ce dernier qui une fois chargé fait des appels asynchrone pour recuperer les informations à afficher ? (j'espere avoir été clair)

1 - oui et non, parce que tu peux avoir une page initiale qui peut être une JSP. L'interêt d'angularJS est de limiter les appels côté serveur pour des manipulations de données.
JSP c'est côté serveur et le but est de créer une page HTML. Angular, c'est côté client et ça sert à rendre ta page HTML finale dynamique. Tu peux parfaitement utiliser les deux en même temps.
2 - Depuis AngularJS, tu peux faire appel à des servlets qui pourront te renvoyer des données uniquement (et pas faire un forward vers une page JSP), et c'est le code client qui te permettra de définir comment ils sont affichés. Tu peux aussi avoir des pages HTML statiques qui contiennent du code Angular qui se chargera à l'initialisation de la page d'aller chercher les éléments à afficher (en faisant des requêtes vers des servlets du coup)
2a - Si tu as un fichier ne contenant aucun élément devant être compilé ou avec des variables provenant des différents contextes, tu as une page statique... Donc autant la qualifier correctement avec une extension HTML en effet. Comme dit plus haut, tu peux faire entièrement avec AngularJS, ou en cumulant les deux.
3 - les deux sont possibles, à toi de voir ce que tu préfères et ce qui est le plus adapté à ton besoin ! Si tu peux coder toute la logique client en angularJS, laisse angular charger et préparer les données. Si tu ne veux utiliser angular que pour mettre à jour des champs au fur et à mesure des manipulations de l'utilisateur, il faudra présenter une page initialement chargée avec toutes les données voulues


Pour faire court, AngularJS n'est pas le remplacement des JSP : angularJS, c'est un framework javascript qui permet de "facilement" mettre à jour des informations en limitant les échanges avec le serveur. Ca permet aussi avec de nombreux outils graphiques de créer des applications très dynamiques.
Ce qui est possible depuis déjà très longtemps soit avec VanillaJs, soit avec les TRES nombreux framework javascript qui se sont succédé ces dernières années

[Yonito]

Tout d'abord merci de tes reponses,

3. les deux sont possibles, à toi de voir ce que tu préfères et ce qui est le plus adapté à ton besoin ! Si tu peux coder toute la logique client en angularJS, laisse angular charger et préparer les données. Si tu ne veux utiliser angular que pour mettre à jour des champs au fur et à mesure des manipulations de l'utilisateur, il faudra présenter une page initialement chargée avec toutes les données voulues

Y'a t'il une solution préférable ? De passer le contenu en parametre à la JSP pour l'affichage des info, ou charger la page "vide" et tout charger avec des appels ajax au chargement de la page (coté client) ?
Si cela depend du contexte alors quels sont les avantages et les inconvenient des deux possibilités ?
Quelle methode est le plus utilisée (reconnu comme meilleur) aujourd'hui ?

1 - oui et non, parce que tu peux avoir une page initiale qui peut être une JSP. L'interêt d'angularJS est de limiter les appels côté serveur pour des manipulations de données.
JSP c'est côté serveur et le but est de créer une page HTML. Angular, c'est côté client et ça sert à rendre ta page HTML finale dynamique. Tu peux parfaitement utiliser les deux en même temps.

De ce que je comprend moi c'est que si on laisse angular se charger du dynamisme de la page, les balises JSP coté serveur qui permettent de generer un HTML dynamique non plus grand interet non ?

Cordialement,

[eulbobo]

Y'a t'il une solution préférable ? De passer le contenu en parametre à la JSP pour l'affichage des info, ou charger la page "vide" et tout charger avec des appels ajax au chargement de la page (coté client) ?
Si cela depend du contexte alors quels sont les avantages et les inconvenient des deux possibilités ?
Quelle methode est le plus utilisée (reconnu comme meilleur) aujourd'hui ?

J'ai déjà travaillé sur différents projets où on a utilisé plusieurs solutions différentes... Et très clairement, c'était plus pour nous amuser que pour relever un quelconque défi technique ou une recherche de performance.

La vraie différence vient du côté serveur par rapport au nombre d'utilisateurs : plus le nombre d'utilisateurs est élevé, plus tu vas avoir tendance à vouloir répartir la charge de traitement au maximum et limiter le travail du serveur qui peut être fait côté client.
Une JSP, c'est juste une façon plus "jolie" et plus rapide de coder une servlet en fait, et ça permet de se concentrer sur la présentation HTML que tu peux récupérer d'une maquelle (et adapter pour ajouter les éléments qui vont bien), mais ça coûte toujours du temps niveau serveur.
Si tu limites les échanges serveurs à du webservice pur (une url avec des paramètres ou un post, qui ne renvoie pas une page mais directement des données), tu supprimes totalement le travail de préparation des données pour la présentation.
La vraie question étant : est-ce que tu en as besoin?

Je ne pourrais pas te faire un état de l'art de ce qui est le meilleur parce que la meilleure solution est celle qui est la mieux adaptée à un besoin. Tu peux utiliser une ferrari pour aller acheter ton pain, ou tu peux utiliser un porte conteneur pour faire le trajet Lille/New York...

En terme d'inconvénients, je vais essayer de lister ceux que je vois

Avantages de tout faire côté serveur (ou presque, ça empêche pas de coller un peu d'ajax ça et là pour améliorer le rendu)
- toute la logique est à un seul endroit !
- tu n'es pas obligé de t'adapter au client (même si c'est très bien géré actuellement, devoir gérer les 28 versions de navigateurs différents pour avoir un rendu/expérience identique, c'est lourd et chiant pour rien !)
- tu n'es pas obligé d'apprendre à faire fonctionner un n-ième framework javascript
Inconvénients :
- ca ne tient pas bien la charge si tu as VRAIMENT BEAUCOUP d'utilisateurs et que tu n'as pas prévu de traitements asynchrones de chargement des données (mais là, on parle du cas où tu auras BEAUCOUP d'utilisateurs en même temps. Tu devrais avoir des problèmes de bande passante et de mémoire avant normalement)

Avantages de faire toute la présentation côté client
- tu n'as pas à savoir comment fonctionne la partie serveur, donc totale déconnexion de la source et utilisation de webservices uniquement pour accéder aux données (donc tu peux avoir un serveur codé en java, C, python, ruby ou fortran, tant qu'il répond à tes requêtes, tu as pas à te poser de questions... Ca peut même être un serveur codé lui même en Angular d'ailleurs)
- Le serveur n'est qu'une source de données (un service), il travaille donc beaucoup moins puisqu'il ne gère pas la présentation du tout. Il tient donc beaucoup mieux la charge face à une augmentation du nombre d'utilisateurs.
Inconvénient
- tu dois apprendre à faire fonctionner un nouveau framework javascript (ca change beaucoup et très rapidement)
- c'est facile dans les 90% cas simples mais qui ne prennent de toute façon que 10% du temps... Pour les cas complexes où tu vas devoir manipuler beaucoup de données côté client, il faut que le client en SOIT CAPABLE (genre avoir assez de mémoire pour manipuler une grande quantité de données sans tout faire crasher)


Personnellement, je préfère la première solution, ce qui ne m'empêche pas de séparer logiquement mes structures et traitements pour limiter leur adhérence. Et tu peux parfaitement déployer plusieurs serveurs applicatifs ayant chacun leur rôle et communiquant entre eux par webservices, donc finalement obtenir la même scalabilité qu'avec un client riche en ayant deux applications différentes déployées à deux endroits différents avec chacun qui gère sa partie : une qui ne fait que la présentation et l'autre qui ne gère que l'accès aux données...

De ce que je comprend moi c'est que si on laisse angular se charger du dynamisme de la page, les balises JSP coté serveur qui permettent de generer un HTML dynamique non plus grand interet non ?

Si tu pars dans la logique que ton serveur web ne fait que servir des données oui.

[hhfr]

Je sais pas si tu es toujours avide d'avis sur ton sujet.

Les jsp étaient clairement la reponse de java au pages php.
Donc en soit pour un developpeur java, pas une tres bonne pratique. Mélange vue et données, berk
JSF est surement une solution plus élégante pour un developpeur java.
GWT est dans le même genre mais vue par Google.
ZK Framework aussi, trés interessant pour contruire des applications web, et non des sites web. Comme GWT d'ailleurs.

Pour angularjs, je t'invite à regarder du coté de http://webcomponents.org/ qui est probablement l'avenir du web avec des implementations tres séduisante style polymer de google.
L'idée est de reprendre le principe des binding, mais avec des UI standard. Bref, je te laisse regarder.

Pour la communication server<->ihm en general avec des appli angular ou knockout ou autre framework js, REST est plutôt previlégié.
L'avantage c'est que ton serveur se charge de faire la serialisation detes objets java en json, et que le json c'est natif pour le javascipt. Donc, tout bénef.
Bien sur tu pourrais generer du json avec des servlet/jsp (bon courage); mais JAX-RS fait tout ca pour toi avecjuste quelques annotations.
Pour y acceder, tu fait un petit appel ajax, et hop tu as ta donnée, plus qu'a la placé dans ton ihm.

Voilà bon dev...

[eulbobo]

Les jsp étaient clairement la reponse de java au pages php.
Donc en soit pour un developpeur java, pas une tres bonne pratique. Mélange vue et données, berk
JSF est surement une solution plus élégante pour un developpeur java.

Les deux sont équivalents pour la présentation des données, c'est juste une autre API avec une logique différente.
Les JSP sont moches quand on mélange tout, mais les JSF peuvent l'être aussi.
Ce qui veut dire que JSP et JSF peuvent être clean si on fait les choses bien.

[hhfr]

Les deux sont équivalents pour la présentation des données, c'est juste une autre API avec une logique différente.
Les JSP sont moches quand on mélange tout, mais les JSF peuvent l'être aussi.
Ce qui veut dire que JSP et JSF peuvent être clean si on fait les choses bien.

Ha ben ca c'est un commentaire utile, comme celui ci d'ailleurs...
Cela peut être clean si on fait les choses bien... Bravo, moi je dit bravo... Tout est dit

JSF est quand même une approche bien plus moderne, basé sur un concept de server centric, comme gwt, et zk.
C'est quand même pas comparable aux JSPs (que j'ai longtemps utilisé ceci dit)