Pour éviter d'utiliser les scriptlets dans ma page JSP?

J'ai été dit que l'utilisation de scriptlets (<%= ... %>) dans mes pages JSP n'est pas une bonne idée.

Quelqu'un peut-il avec un peu plus de java/jsp expérience s'il vous plaît me donner quelques indications quant à la façon de modifier ce code afin que ses "meilleures pratiques", quoi que cela peut être?

Cette JSP est en fait mon sitemesh principal décorateur page. Fondamentalement, mon web design dispose d'une barre d'onglets et un sous-menu, et je souhaite en quelque sorte mettre en surbrillance l'onglet en cours et de montrer le bon sous-menu en regardant le courant de l'URI de la requête.

<%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator" prefix="decorator" %>

<html>
<head>
  <title>My Events - <decorator:title /></title>
  <link href="<%= request.getContextPath() %>/assets/styles.css" rel="stylesheet" type="text/css" />
</head>
<body>

<div class="tabs">
  <a 
    <%= request.getRequestURI().contains("/events/") ? "class='selected'" : "" %>
    href='<%= request.getContextPath() %>/events/Listing.action'>Events</a>
  <a 
    <%= request.getRequestURI().contains("/people/") ? "class='selected'" : "" %>
    href='<%= request.getContextPath() %>/people/Listing.action'>People</a>
</div>

<div class="submenu">
  <% if(request.getRequestURI().contains("/events/")) { %>
    <a href="Listing.action">List of Events</a>
    |<a href="New.action">New Event</a>
  <% } %>
  <% if(request.getRequestURI().contains("/people/")) { %>
    <a href="Listing.action">List of People</a>
    |<a href="New.action">New Person</a>
  <% } %>  
  &nbsp;
</div>

<div class="body">
  <decorator:body />
</div>

</body>
</html>

Merci à tous

  • En aparté, est " <%= request.getContextPath() %>' une utilisation acceptable des scriptlets qui n'est pas mal à ce point?
  • Vous devriez commencer à utiliser facelets pour la création de modèles. Vous oblige à coder correctement.
  • Dites-vous utiliser facelets au lieu de sitemesh?
  • double possible de stackoverflow.com/questions/3177733/...
InformationsquelleAutor Chris | 2010-02-02
  1. 42

    Je pense que ça aide plus si vous le voyez de vos propres yeux qu'il peut être fait entièrement sans scriptlets.

    Ici est un 1 sur 1 réécrire avec l'aide, entre autres, JSTL (il suffit de déposer jstl-1.2.jar dans /WEB-INF/lib) de base et fonctions taglib:

    <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>

<html>
<head>
  <title>My Events - <decorator:title /></title>
  <link href="${pageContext.request.contextPath}/assets/styles.css" rel="stylesheet" type="text/css" />
</head>
<body>

<div class="tabs">
  <a 
    ${fn:contains(pageContext.request.requestURI, '/events/') ? 'class="selected"' : ''}
    href="${pageContext.request.contextPath}/events/Listing.action">Events</a>
  <a 
    ${fn:contains(pageContext.request.requestURI, '/people/') ? 'class="selected"' : ''}
    href="${pageContext.request.contextPath}/people/Listing.action">People</a>
</div>

<div class="submenu">
  <c:if test="${fn:contains(pageContext.request.requestURI, '/events/')}">
    <a href="Listing.action">List of Events</a>
    |<a href="New.action">New Event</a>
  </c:if>
  <c:if test="${fn:contains(pageContext.request.requestURI, '/people/')}">
    <a href="Listing.action">List of People</a>
    |<a href="New.action">New Person</a>
  </c:if>
  &nbsp;
</div>

    Voici un plus optimisé de réécriture, notez que j'ai utilisé c:set de "cache" expression des résultats pour la réutilisation et que j'utilise HTML <base> balise pour éviter de mettre le chemin de contexte dans chaque lien (juste faire toute relative de l'URL de votre page web par rapport à elle-sans le slash!):

    <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>

<c:set var="isEvents" value="${fn:contains(pageContext.request.requestURI, '/events/')}" />
<c:set var="isPeople" value="${fn:contains(pageContext.request.requestURI, '/people/')}" />

<html>
<head>
  <title>My Events - <decorator:title /></title>
  <base href="${pageContext.request.contextPath}">
  <link href="assets/styles.css" rel="stylesheet" type="text/css" />
</head>
<body>

<div class="tabs">
  <a ${isEvents ? 'class="selected"' : ''} href="events/Listing.action">Events</a>
  <a ${isPeople ? 'class="selected"' : ''} href="people/Listing.action">People</a>
</div>

<div class="submenu">
  <c:if test="${isEvents}">
    <a href="Listing.action">List of Events</a>|<a href="New.action">New Event</a>
  </c:if>
  <c:if test="${isPeople}">
    <a href="Listing.action">List of People</a>|<a href="New.action">New Person</a>
  </c:if>
  &nbsp;
</div>

    Il peut effectivement être plus optimisé si vous recueillir toutes ces "codé en dur" des valeurs comme events et people et liens textes dans un Map dans le champ d'application et l'utilisation sous chaque la JSTL <c:forEach> pour afficher les onglets.

    À votre réelle question, vous pouvez désactiver scriptlets (et d'obtenir des erreurs d'exécution sur l'utilisation de celle-ci) en ajoutant l'entrée suivante dans webapp est web.xml. Il peut aider à repérer supervisé les scriptlets.

    <jsp-config>
    <jsp-property-group>
        <url-pattern>*.jsp</url-pattern>
        <scripting-invalid>true</scripting-invalid>
    </jsp-property-group>
</jsp-config>

    Pour en savoir plus sur EL, vérifier la Java EE tutoriel, partie II, chapitre 5. Implicite EL objets, tels que des ${pageContext} sont décrites ici. Pour en savoir plus sur la JSTL, vérifier la Java EE tutoriel, partie II, chapitre 7. Notez que JSTL et EL sont deux choses distinctes. JSTL est un standard taglib et EL permet seulement d'accéder à backend de données par programmation. Bien qu'il est normalement utilisé dans les taglibs comme JSTL, il peut également être utilisé de façon autonome dans le modèle de texte.

    • Si vous comparez le "avant" et "après" des modèles, vous verrez qu'ils sont à peu près la même. Je ne vois pas comment ce dernier est automatiquement mieux que l'ancien (d'ailleurs à la recherche d'un petit peu plus propre).
    • Honnêtement, je pense que le plus gros atout de la JSTL, c'est qu'il ne vous donne pas la liberté d'écrire n'importe quel code qui vient à l'esprit dans votre JSP. JSTL vous donne la plupart de tous les outils dont vous avez besoin pour écrire des modèles, pas des contrôleurs, la logique métier des gestionnaires ou des objets d'accès aux données.
    InformationsquelleAutor BalusC
  2. 9

    En aparté, est <%= request.getContextPath() %> une utilisation acceptable des scriptlets qui n'est pas mal à ce point?

    Cela peut être une opinion impopulaire, mais si tout ce que vous faites sont de simples conditions et les insertions de texte, je ne trouve pas beaucoup de faute dans l'utilisation des scriptlets. (Note de l' si)

    Je serais probablement utiliser JSTL et l'expression de la langue, mais surtout parce qu'il peut être moins de frappe, IDE et un soutien peut être mieux (mais un bon JSP IDE pouvez également trouver des disparus de fermeture crochets et des trucs comme ça).

    Mais fondamentalement (comme dans "garder la logique des modèles"), je ne vois aucune différence entre

    <% if(request.getRequestURI().contains("/events/")) { %>

    et 

    ${fn:contains(pageContext.request.requestURI, '/events/')
    • Ok super! Je pensais que j'étais la seule à avoir cette opinion!
    • Je pense que le contexte ici est l'une des meilleures pratiques qui entre en jeu plus lorsque vous n'êtes pas le seul développement ou le maintien d'un modèle. Bien que fonctionnellement, il n'y a pas de différence dans votre exemple, vous avez mis la priorité de l'aide de scriptlets et quelqu'un qui ne sait pas mieux tomber dans certains arbitraire de code java qui change d'un modèle d'état. Juste quelque chose à considérer. J'aime l'idée de les désactiver comme BalusC mentionnés ci-dessus.
    InformationsquelleAutor Thilo
  3. 6

    Ce n'est pas une réponse directe à votre question (et il y a déjà plusieurs bons, donc je ne vais pas essayer de l'ajouter à cela), mais vous ne mentionnez:

    Quelqu'un peut-il avec un peu plus de java/jsp
    expérience s'il vous plaît me donner quelques
    indications quant à la façon de modifier ce code
    donc son plus "meilleures pratiques", quelle que soit
    qui peut être    ?

    À mon avis, les meilleures pratiques, en ce qui concerne JSP, c'est qu'il doit être strictement un moteur de template, et rien de plus (c'est à dire, pas de logique métier là). À l'aide de JSTL, comme beaucoup l'ont souligné, certainement vous aide à y arriver, mais même avec JSTL, c'est facile à faire beaucoup dans une JSP.

    Personnellement, j'aime à suivre les règles énoncées dans L'application Stricte du Modèle-Vue de la Séparation dans les Moteurs de Template par le Terence Parr lors de l'élaboration dans les JSP. Le document mentionne l'objectif de création de modèles de moteurs, de séparation de modèle et de vue), et les caractéristiques d'un bon moteur de template. Il prend un bon coup d'oeil à JSP et des points façons ce n'est pas un bon moteur de template. Il n'est pas surprenant, JSP est fondamentalement trop puissant et permet aux développeurs d'en faire trop. Je recommande fortement la lecture de ce document, et il va vous aider à vous limiter à la "bonne" pièces de JSP.

    Si vous ne devez lire qu'une section dans ce livre, lisez le chapitre 7, qui comprend les règles suivantes:

    1. la vue ne peut pas modifier le modèle soit directement en modifiant le modèle
      objets de données ou par appel de méthodes sur
      le modèle de causer des effets secondaires.
      C'est un modèle qui peut accéder aux données
      à partir du modèle et appeler des méthodes, mais
      ces références doivent être des effets secondaires
      gratuit. Cette règle découle partiellement
      parce que les références de données doit être
      afin insensible à la casse. Voir La Section 7.1.
    2. la vue ne peut pas effectuer des calculs sur les données dépendantes
      les valeurs       parce que les calculs peuvent
      changer dans le futur et ils devraient
      être bien encapsulé dans le modèle en
      tous les cas. Par exemple, la vue ne peut pas
      calculer livre prix de vente comme
      “$prix*.90”. Pour être indépendant de la
      le modèle, la vue ne peut pas faire
      hypothèses sur la signification des données.
    3. la vue ne peut pas comparer des données dépendant des valeurs, mais peut tester l'
      propriétés de données telles que
      la présence/absence ou la longueur d'un
      plusieurs valeurs de données de la valeur. Des Tests comme
      $bloodPressure<120 doit être déplacé
      le modèle que les médecins aiment à garder
      réduire le max de la pression systolique
      sur nous. Les Expressions de la vue doit être
      remplacé par un test de présence d'un
      la valeur de la simulation d'un booléen comme
      $bloodPressureOk!=null sortie de Modèle
      peut être conditionnelle à ce que le modèle de données et
      les calculs, le conditionnel juste
      doit être calculé dans le modèle. Même
      tests simples qui font les valeurs négatives
      le rouge doit être calculée dans le modèle;
      le bon niveau d'abstraction est usu-
      allié à quelque chose de plus haut niveau comme
      du ministère “x est en train de perdre de l'argent”.
    4. la vue ne peut pas faire de type de données à des hypothèses. Certains types d'hypothèses sont
      évident lorsque la vue suppose de données
      la valeur est une date, par exemple, mais plus
      subtil type hypothèses apparaissent: Si un
      modèle suppose $userID est un
      entier, le programmeur ne peut pas
      modifier cette valeur non-numérique
      dans le modèle sans rupture de la
      de modèle. Cette règle interdit de tableau
      l'indexation comme colorCode[$sujet] et
      $nom[$ID] de La voir d'autres ne peuvent pas
      l'appel de méthodes avec des arguments en être la cause
      (statiquement ou dynamiquement) il est
      l'hypothèse d'un type d'argument, à moins que l'on
      ne pourrait garantir que le modèle de la méthode
      simplement traités comme des objets.
      En plus de graphistes ne sont pas
      les programmeurs attendent à invoquer
      de méthodes et de savoir ce qu'à passer est
      irréaliste.
    5. données à partir du modèle ne doit pas contenir d'affichage ou d'informations de mise en page.
      Le modèle ne peut pas passer n'importe quel écran
      informations à la vue déguisé en
      valeurs de données. Cela inclut ne pas passer
      le nom d'un modèle à appliquer à
      d'autres valeurs de données.

    D'ailleurs, Terence a créé son propre moteur de template appelé Modèle De Chaîne De qui soi-disant fait un très bon travail de faire respecter ces règles. Je n'ai pas d'expérience personnelle avec elle, mais aimerais le vérifier sur mon prochain projet.

    InformationsquelleAutor Jack Leow
  4. 6

    Scriptlets ne sont pas la pire chose dans le monde. Une considération importante est de penser à qui va être de maintenir le code. Si ses concepteurs web qui n'ont pas beaucoup de Java d'expérience, vous êtes probablement mieux d'aller avec les bibliothèques de balises. Toutefois, si les développeurs Java sont en train de faire l'entretien, il peut être plus facile à aller avec les scriptlets.

    Si vous vous retrouvez à l'aide d'une bibliothèque de balises et de la JSTL, vous attendez le responsable d'apprendre également la bibliothèque de balises et de savoir JSTL. Certains développeurs sera très bien pour ce que c'est une compétence qu'ils veulent ou ont déjà, mais pour certains développeurs, qui n'ont à traiter avec les Jsp tous les quelques mois, il peut être beaucoup moins pénible de travailler avec clairement écrit scriptlets écrite à nice, familier Java.

    InformationsquelleAutor Spike Williams
  5. 3

    Vous voudrez peut-être commencer par l'utilisation de bibliothèques de balises. Vous pouvez utiliser le standard tag library JSTL de faire la plupart des choses en commun que vous avez besoin scriplets pour. Il existe de nombreuses autres plus riches bibliothèques de balises qui sont utilisés comme dans la struts2-cadre ou à partir de apache.

    par exemple

      <c:if test="${your condition}">
       Your Content
  </c:if>

    serait de remplacer le votre si consolidés.

    InformationsquelleAutor Vincent Ramdhanie
  6. 3

    La solution privilégiée pour les scriptlets est la JSTL langage d'expression; iciune bonne vue d'ensemble. Vous aurez besoin d'ajouter de la taglib comme suit:

    <%@ taglib uri='http://java.sun.com/jsp/jstl/core' prefix='c' %>

    Comme un exemple, JSTL fournit un tas d'implicite des objets que vous donner les trucs dont vous avez besoin; celui que vous voulez, c'est pageContext.request.

    De sorte que vous pouvez remplacer <%request.getRequestURI%> avec ${pageContext.request.requestURI}.

    Vous pouvez faire des conditionnelles à l'aide de <c:if> balises.

    InformationsquelleAutor Jacob Mattison
  7. 2

    Vous devrez utiliser des framework web. Ou au moins certains de pratique taglib. Ou un template enginge comme FreeMarker.

    Ad cadres:

    Si vous aimez JSP façon de coder, alors je vous suggère de Struts 2.

    <s:if test="%{false}">
    <div>Will Not Be Executed</div>
</s:if>
<s:elseif test="%{true}">
    <div>Will Be Executed</div>
</s:elseif>
<s:else>
    <div>Will Not Be Executed</div>
</s:else>

    Puis il y a la composante orientée JSF.

    Si vous aimez la programmation orientée objet et de tout coder en Java, essayez Apache Wicket (mon préféré) ou Google Web Toolkit.

    InformationsquelleAutor Ondra Žižka