Tous les développeurs qui utilisent aujourd'hui des servlets connaissent JSP, une technologie Web inventée par Sun Microsystems et qui a consacré beaucoup d'efforts à promouvoir et à développer la technologie des servlets. JSP détache le code HTML du servlet, accélérant ainsi le développement d'applications Web et la maintenance des pages. En fait, le document officiel "Application Development Model" publié par Sun va encore plus loin : "La technologie JSP doit être considérée comme un standard, et les servlets peuvent être considérées comme un complément dans la plupart des cas." Écoutez la version avis).
Le but de cet article est d'évaluer la plausibilité de cette affirmation -- en comparant JSP à une autre technologie basée sur des servlets : les moteurs de modèles.
Problèmes liés à l'utilisation directe des servlets
Au départ, les servlets ont été inventés et le monde entier a vu leur supériorité. Les pages Web dynamiques basées sur des servlets peuvent être exécutées rapidement, peuvent être facilement transférées entre plusieurs serveurs et peuvent être parfaitement intégrées à la base de données principale. Les servlets sont largement acceptés comme plate-forme privilégiée pour les serveurs Web.
Cependant, le code HTML qui est généralement implémenté de manière simple nécessite désormais que le programmeur appelle out.println() pour chaque ligne HTML, ce qui est devenu un problème sérieux dans les applications de servlets réelles. Le contenu HTML doit être implémenté via du code, ce qui constitue une tâche fastidieuse et chronophage pour les grandes pages HTML. De plus, les personnes responsables du contenu Web ont dû embaucher des développeurs pour effectuer toutes les mises à jour. C’est pour cette raison que les gens recherchent une meilleure solution.
JSP arrive !
JSP 0.90 est apparu. Dans cette technique, vous intégrez du code Java dans un fichier HTML et le serveur créera automatiquement un servlet pour la page. JSP est considéré comme un moyen simple d'écrire des servlets. Tout le HTML peut être obtenu directement sans avoir à appeler out.println(), et la personne responsable du contenu de la page peut modifier le HTML directement sans risquer de casser le code Java.
Cependant, avoir des créateurs de pages et des développeurs travaillant sur le même fichier n'était pas idéal, et l'intégration de Java dans HTML s'est avérée aussi embarrassante que l'intégration de HTML dans Java. Il est toujours difficile de lire un fouillis de code.
En conséquence, les gens sont devenus plus matures dans l’utilisation de jsp et ont davantage utilisé les JavaBeans. Les beans contiennent le code de logique métier requis par jsp. La majeure partie du code JSP peut être extraite et insérée dans le bean, ne laissant qu'une très petite quantité de balisage pour appeler le bean.
Récemment, les gens ont commencé à penser que les pages JSP de cette manière sont vraiment comme des vues. Ils deviennent un composant permettant d'afficher les résultats des demandes des clients. Alors les gens se demanderont pourquoi ne pas envoyer une requête directement à la vue ? Que se passe-t-il si la vue cible ne convient pas à la demande ? Après tout, de nombreuses requêtes offrent de multiples possibilités pour obtenir la vue des résultats. Par exemple, la même requête peut produire une page réussie, un rapport d'erreurs d'exception de base de données ou un rapport d'erreurs de paramètres manquants. La même requête peut produire une page en anglais ou une page en espagnol, selon la région du client. Pourquoi le client doit-il envoyer la requête directement à la vue ? Pourquoi le client ne devrait-il pas envoyer la requête à un composant serveur générique et laisser le serveur décider de ce que renvoie la vue JSP ?
Cela a conduit de nombreuses personnes à accepter ce que l'on appelle désormais « » Model 2" Design, il s'agit d'un modèle basé sur un modèle-vue-contrôleur défini dans JSP 0.92. Dans cette conception, les requêtes sont envoyées à un contrôleur de servlet, qui exécute la logique métier et génère un « modèle » de données similaire à afficher. Ces données sont ensuite envoyées en interne vers une « vue » JSP pour être affichées, ce qui donne à la page JSP l'apparence d'un JavaBean intégré classique. La page JSP appropriée peut être sélectionnée pour être affichée en fonction de la logique interne du servlet responsable du contrôle. De cette façon, le fichier JSP devient une belle vue modèle. Il s'agit d'un autre développement qui a été salué par d'autres développeurs à ce jour.
Entrez dans les moteurs de modèles
et utilisez le moteur de modèles pour remplacer le JSP à usage général. La conception ultérieure deviendra plus simple, la syntaxe sera plus simple, le message d'erreur sera plus facile à lire. , et les outils seront meilleurs. Plusieurs sociétés ont réalisé de tels moteurs, la plus connue est probablement WebMacro ( http://webmacro.org , de Semiotek), et leur moteur est gratuit.
Les développeurs doivent comprendre que le choix d'un moteur de modèles pour remplacer JSP offre de tels avantages techniques, qui constituent également quelques-uns des défauts de jsp :
Problème n°1 : le code Java est trop modélisé
. Bien qu'il soit considéré comme une mauvaise conception, JSP tente toujours d'ajouter Java. code vers la page Web. C'est un peu ce que Java faisait autrefois, qui était une modification simplifiée des moteurs de modèles C++, qui l'a également simplifié en supprimant le code source de niveau inférieur dans jsp. Les moteurs de modèles implémentent une meilleure conception.
Question n°2 : Exiger du code Java
Il est nécessaire d'écrire du code Java dans la page JSP. Par exemple, supposons qu'une page détermine le contexte racine de l'application Web actuelle et mène à sa page d'accueil.
Il est préférable d'utiliser le code Java suivant dans JSP :
＜a href="＜%= request.getContextPath() %＞/index.html"＞Page d'accueil＜/a＞
Vous pouvez essayer d'éviter le code Java et utiliser la balise
property="contextPath"/＞/index.html"＞HomePage＜/a＞
En utilisant le moteur de modèle, il n'y a pas de code Java ni de syntaxe laide. Voici comment il est écrit dans WebMacro selon les mêmes exigences :
＜a href="$ Request.ContextPath ;/index.html">Page d'accueil
Dans WebMacro, ContextPath est utilisé comme attribut de la variable $Request, en utilisant une syntaxe de type Perl. D'autres moteurs de modèles utilisent d'autres types de syntaxe.
En regardant un autre exemple, supposons qu'une "vue" avancée doive définir un cookie pour enregistrer la configuration des couleurs par défaut de l'utilisateur - cette tâche semble probablement être effectuée par la vue plutôt que par le contrôleur de servlet. Il doit y avoir un tel code Java dans JSP :
<% Cookie c = new Cookie("colorscheme", "blue"); réponse.addCookie(c); %>
Il n'y a pas de code Java dans WebMacro :
#set $Cookie.colorscheme = "bleu"
comme dernier ion, si vous souhaitez récupérer la configuration des couleurs dans le cookie d'origine. Pour JSP, nous pouvons penser à une classe d'outils correspondante pour aider, car il deviendrait ridicule et difficile de faire des choses de si bas niveau directement avec getCookies(). Dans JSP :
<% String colourscheme = ServletUtils.getCookie(request, "colorscheme"); %>
Il n'est pas nécessaire de classes d'outils dans WebMacro, généralement : $Cookie.colorscheme.Value. Pour les graphistes qui écrivent du JSP, quelle syntaxe est la plus facile à apprendre ?
JSP 1.1 a introduit des balises personnalisées qui permettent à des balises arbitraires de type HTML d'exécuter du code Java en arrière-plan dans les pages JSP. Cela aura une certaine valeur, mais seulement s'il existe une bibliothèque de balises standardisée, largement connue et complète. Il n’existe actuellement aucune bibliothèque de balises de ce type.
Problème n°3 : les tâches simples sont toujours fatiguantes
Même les tâches simples, comme l'inclusion d'en-têtes et de pieds de page, sont encore très difficiles dans JSP. Supposons qu'il existe un modèle « d'en-tête » et un « pied de page » à inclure dans toutes les pages, et que chaque modèle doit contenir le titre de la page actuelle dans le contenu.
La meilleure méthode en JSP est la suivante :
＜% Titre de la chaîne = "Le titre de la page" %＞
＜%@include file="/header.jsp" %＞
...le contenu de votre page...
＜%@ include file="/footer.jsp" %＞
Les concepteurs de pages doivent se rappeler de ne pas omettre le point-virgule dans la première ligne et de définir le titre sous forme de chaîne. De plus, /header.jsp et /footer.jsp doivent se trouver dans le répertoire racine et doivent être des fichiers entièrement accessibles.
Inclure des en-têtes et des pieds de page dans WebMacro est relativement simple :
#set $title = "Le titre de la page"
#analyser "en-tête.wm"
Votre contenu ici
#parse "footer.wm"
Il n'y a pas de point-virgule ni de définition de titre à retenir pour les concepteurs, et les fichiers .wm peuvent être placés dans un chemin de recherche personnalisable.
Problème n°4 : boucles très épaisses
Faire des boucles dans JSP est difficile. Ici, JSP est utilisé pour imprimer à plusieurs reprises le nom de chaque objet FAI.
<%
Énumération e = list.elements();
tandis que (e.hasMoreElements()) {
out.print("Le prochain nom est ");
out.println(((ISP)e.nextElement()).getName());
out.print("
");
}
%>
Peut-être qu'il y aura des balises définies par l'utilisateur pour faire ces boucles un jour. Il en va de même pour "si". Les pages JSP peuvent ressembler à du code Java étrange. Et en même temps, la boucle webmacro est magnifique :
#foreach $isp dans $isps {
Le nom suivant est $isp.Name
}
Si nécessaire, la directive #foreach peut être facilement remplacée par une directive #foreach-backwards personnalisée.
Si vous utilisez jsp, cela peut ressembler à ceci : (Voici une balise
Le nom suivant est ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
Le concepteur choisira naturellement le premier.
Problème n°5 : messages d'erreur inutiles
Les JSP affichent souvent des messages d'erreur surprenants. En effet, la page est d'abord convertie en servlet puis compilée. De bons outils JSP peuvent relativement augmenter la probabilité de trouver l'emplacement d'une erreur, mais même les meilleurs outils ne peuvent pas rendre tous les messages d'erreur facilement lisibles. En raison du processus de conversion, certaines erreurs peuvent être impossibles à identifier pour l'outil.
Par exemple, supposons qu'une page JSP doive créer un titre commun à toutes les pages. Il n'y a rien de mal avec le code suivant :
＜% static String title = "Global title" ; %＞
Mais Tomcat fournira le message d'erreur suivant :
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70 : Déclaration attendue.
nombre entier statique = 0 ;
^
Ces informations pensent que le script ci-dessus est placé dans la méthode _jspService() et que les variables statiques ne sont pas autorisées à être placées dans la méthode. La syntaxe doit être <% ! %>. Il est difficile pour les concepteurs de pages de lire ces messages d'erreur. Même les meilleures plateformes ne sont pas à la hauteur à cet égard. Même déplacer tout le code Java hors de la page ne résout pas le problème. Aussi, qu'est-ce qui ne va pas avec l'expression suivante ?
<% compte %>
Tomcat donne :
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56 : nombre de classes introuvable dans
déclaration de type.
compter
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59 : Déclaration invalide.
out.write("rn");
^
En d'autres termes, c'est juste une marque manquante. Cela devrait être <%= count %>.
Étant donné que le moteur de modèle peut être généré directement à partir du fichier modèle sans aucune traduction dramatique en code, il est très facile de fournir un rapport d'erreurs approprié. Par analogie, lorsqu'une commande en langage C est tapée dans la ligne de commande du shell Unix, vous ne voulez pas que le shell génère un programme C pour exécuter la commande, mais vous avez juste besoin que le shell interprète simplement la commande et l'exécute, et signaler directement toute erreur.
Problème n°6 : avoir besoin d'un compilateur
JSP nécessite un compilateur placé sur le serveur Web. Cela est devenu problématique car Sun a refusé d'abandonner la bibliothèque tools.jar qui contenait son compilateur javac. Le serveur Web peut inclure un compilateur tiers tel que Jikes d'IBM. Mais un tel compilateur ne fonctionne pas correctement sur toutes les plateformes (écrites en C++) et n'est pas propice à la construction d'un serveur Web Java pur. JSP dispose d'une option de précompilation qui aide, même si elle n'est pas parfaite.
Problème n°7 : gaspillage d'espace
JSP consomme de la mémoire et de l'espace disque supplémentaires. Pour chaque fichier JSP de 30 Ko sur le serveur, un fichier de classe correspondant de plus de 30 Ko doit être généré. Double efficacement l'espace disque dur. Étant donné qu'un fichier JSP peut facilement inclure un fichier de données volumineux via <%@ include> à tout moment, cette préoccupation a une signification très pratique. Dans le même temps, les données du fichier de classe de chaque JSP doivent être chargées dans la mémoire du serveur, ce qui signifie que la mémoire du serveur doit sauvegarder pour toujours l'intégralité de l'arborescence des documents JSP. Quelques JVM ont la capacité de déplacer les données des fichiers de classe depuis la mémoire ; cependant, le programmeur n'a généralement aucun contrôle sur les règles de redéclaration, et la redéclaration peut ne pas être très efficace pour les grands sites. Pour les moteurs de modèles, l'espace est économisé car aucun deuxième fichier n'est généré. Les moteurs de modèles offrent également aux programmeurs un contrôle total sur la façon dont les modèles sont mis en cache en mémoire.
Il existe également quelques problèmes liés à l'utilisation du moteur de modèle :
Problème de modèle n°1 : il n'est pas strictement défini
. La manière dont le moteur de modèle doit fonctionner n'est pas strictement définie. Cependant, par rapport à JSP, cela n'est en réalité pas très important. Contrairement à JSP, les moteurs de modèles n'ont pas d'exigences particulières pour le serveur Web : tout serveur prenant en charge les servlets peut prendre en charge les moteurs de modèles (y compris les serveurs API 2.0 tels qu'Apache/JServ). ne supporte pas entièrement JSP) ! Si une concurrence saine pour la meilleure conception de moteur de modèles avait pu provoquer une innovation éblouissante, en particulier avec la promotion de l'open source (permettant aux idées de se pousser et de se promouvoir), alors la WebMacro d'aujourd'hui sera comme Perl. . Ce n'est pas strictement défini mais la promotion des organisations open source est sa norme.
Problème de modèle n°2 : non reconnu
Les moteurs de modèles ne sont pas largement connus. JSP occupe un énorme marché commercial et est profondément enraciné dans le cœur des gens. L'utilisation de moteurs de modèles g ne peut être qu'une technologie alternative qui n'est pas comprise.
Problème de modèle n°3 :
les moteurs de modèles non déployés ne sont pas encore hautement configurés. Il n'y a pas de test de performances ni de comparaison entre le moteur de modèle et JSP. En théorie, une implémentation de moteur de modèles bien déployée devrait correspondre à un JSP bien déployé ; cependant, étant donné que des tiers ont fait une si forte pression en faveur de jsp, seul jsp est bien déployé.
Le rôle de JSP
Bien entendu, JSP aura certainement sa place dans le futur. La similitude entre JSP et ASP se voit même à partir des noms, ils ne diffèrent que par une lettre. Par conséquent, si les utilisateurs d'ASP doivent passer à Java, l'environnement JSP très similaire jouera un rôle important dans cette promotion. Le rôle de maintenir cette relation correspondante avec ASP devrait également être une considération clé pour les concepteurs qui lancent JSP.
Le point ici, cependant, est qu’il existe une grande différence entre ce qui profite aux travailleurs qui s’installent dans un nouvel environnement et si c’est réellement la meilleure façon d’utiliser cet environnement.
JSP montre de plus en plus qu'il devient l'une des technologies Java les plus importantes et permet aux gens de quitter le monde de l'ASP. Ainsi, Sun soutiendra cette solide analyse de rentabilisation, et les partisans de la technologie Java apporteront également un plus grand soutien.
Cependant, ce n’est pas la meilleure solution pour la plateforme Java. Cela fera apparaître la solution Java comme une solution sans Java.