scriptlet example - Comment éviter le code Java dans les fichiers JSP?




openclassroom tutorial (24)

Je suis nouveau à Java EE et je sais que quelque chose comme les trois lignes suivantes

<%= x+1 %>
<%= request.getParameter("name") %>
<%! counter++; %>

est une méthode de codage à l'ancienne et dans la version 2 de JSP il existe une méthode pour éviter le code Java dans les fichiers JSP. Quelqu'un peut-il me dire s'il vous plaît les lignes alternatives JSP 2, et ce que cette technique est appelée?


Answers

Si vous voulez simplement éviter les inconvénients du codage Java dans JSP, vous pouvez le faire même avec des scriplets. Il suffit de suivre une certaine discipline pour avoir un minimum de Java dans JSP et presque pas de calcul et de logique dans la page JSP.

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%//instantiate a JSP controller
MyController clr = new MyController(request, response);

//process action if any
clr.process(request);

//process page forwaring if necessary

//do all variable assignment here
String showMe = clr.getShowMe();%>

<html>
    <head>
    </head>
    <body>
        <form name="frm1">
            <p><%= showMe %>
            <p><% for(String str : clr.listOfStrings()) { %>
            <p><%= str %><% } %>

            // and so on   
        </form>
    </body>
</html>

En utilisant des balises JSTL avec l'expression EL, vous pouvez éviter cela. Mettez les choses suivantes dans votre page jsp:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

Apprenez à personnaliser et à écrire vos propres tags en utilisant JSTL

Notez que EL est EviL (exceptions d'exécution, refactoring)
Wicket peut être mal aussi (performance, laborieux pour les petites applications ou simple niveau de vue)

Exemple de java2s ,

Cela doit être ajouté au fichier web.xml de l'application web

<taglib>
    <taglib-uri>/java2s</taglib-uri>
    <taglib-location>/WEB-INF/java2s.tld</taglib-location>
</taglib>

créer un fichier: java2s.tld dans le / WEB-INF /

<!DOCTYPE taglib
  PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
   "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">

<!-- a tab library descriptor -->
<taglib xmlns="http://java.sun.com/JSP/TagLibraryDescriptor">
    <tlib-version>1.0</tlib-version>
    <jsp-version>1.2</jsp-version>
    <short-name>Java2s Simple Tags</short-name>

    <!-- this tag manipulates its body content by converting it to upper case
    -->
    <tag>
        <name>bodyContentTag</name>
        <tag-class>com.java2s.BodyContentTag</tag-class>
        <body-content>JSP</body-content>
        <attribute>
          <name>howMany</name>
        </attribute>
    </tag>
</taglib>

compilez le code suivant dans WEB-INF \ classes \ com \ java2s

package com.java2s;

import java.io.IOException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.tagext.BodyTagSupport;

public class BodyContentTag extends BodyTagSupport{
    private int iterations, howMany;

    public void setHowMany(int i){
        this.howMany = i;
    }

    public void setBodyContent(BodyContent bc){
        super.setBodyContent(bc);
        System.out.println("BodyContent = '" + bc.getString() + "'");
    }

    public int doAfterBody(){
        try{    
            BodyContent bodyContent = super.getBodyContent();
            String bodyString  = bodyContent.getString();
            JspWriter out = bodyContent.getEnclosingWriter();

            if ( iterations % 2 == 0 ) 
                out.print(bodyString.toLowerCase());
            else
                out.print(bodyString.toUpperCase());

            iterations++;
            bodyContent.clear(); // empty buffer for next evaluation
        }
        catch (IOException e) {
            System.out.println("Error in BodyContentTag.doAfterBody()" + e.getMessage());
            e.printStackTrace();
        } // end of catch

        int retValue = SKIP_BODY;

        if ( iterations < howMany ) 
            retValue = EVAL_BODY_AGAIN;

        return retValue;
    }
}

Démarrer le serveur et charger le bodyContent.jsp dans le navigateur

<%@ taglib uri="/java2s" prefix="java2s" %>
<html>
    <head>
        <title>A custom tag: body content</title>
    </head>
    <body>
        This page uses a custom tag manipulates its body content.Here is its output:
        <ol>
            <java2s:bodyContentTag howMany="3">
            <li>java2s.com</li>
            </java2s:bodyContentTag>
        </ol>
    </body>
</html>

afin d'éviter le code java dans les fichiers JSP java fournit maintenant des bibliothèques de balises comme JSTL java a également créé JSF dans lequel vous pouvez écrire toutes les structures de programmation sous la forme de balises


Vous avez soulevé une bonne question et même si vous avez de bonnes réponses, je vous suggère de vous débarrasser de JSP. C'est une technologie dépassée qui finira par mourir. Utilisez une approche moderne, comme les moteurs de gabarit. Vous aurez une séparation très claire des couches d'affaires et de présentation, et certainement pas de code Java dans les modèles, de sorte que vous pouvez générer des modèles directement à partir du logiciel d'édition de présentation Web, dans la plupart des cas en utilisant WYSIWYG.

Et certainement rester loin des filtres et pré et post-traitement, sinon vous pouvez faire face à des difficultés de support / débogage puisque vous ne savez toujours pas où la variable obtient la valeur.


Si quelqu'un est vraiment contre la programmation dans plusieurs langues , je suggère GWT, théoriquement vous pouvez éviter tous les éléments JS et HTML, car Google Toolkit transforme tout le client et le code partagé en JS, vous n'aurez aucun problème avec eux, donc vous avez un webservice sans codage dans d'autres langues. Même vous pouvez utiliser un CSS par défaut quelque part comme il est donné par les extensions (smartGWT ou Vaadin). Vous n'avez pas besoin d'apprendre des dizaines d'annotations.

Bien sûr, si vous voulez, vous pouvez vous pirater dans les profondeurs du code et injecter JS et enrichir votre page HTML, mais vraiment vous pouvez l'éviter si vous voulez, et le résultat sera bon comme il a été écrit dans d'autres cadres. Je dis vaut la peine d'essayer, et le GWT de base est bien documenté.

Et bien sûr, de nombreux programmeurs ont décrit ou recommandé plusieurs autres solutions. GWT est pour les personnes qui ne veulent vraiment pas faire face à la partie Web ou pour la minimiser.


JSTL propose des tags pour les conditionnels, les boucles, les sets, les get, etc. Par exemple:

<c:if test="${someAttribute == 'something'}">
   ...
</c:if>

JSTL fonctionne avec les attributs de requête - ils sont le plus souvent définis dans la requête par une servlet, qui transmet à la JSP.


L'utilisation de scriptlets dans les pages JSP n'est pas une bonne pratique.

Au lieu de cela, vous pouvez utiliser:

  1. Tags JSTL
  2. Expressions EL
  3. Balises personnalisées: vous pouvez définir vos propres balises à utiliser.

Prière de se référer à:

  1. http://docs.oracle.com/javaee/1.4/tutorial/doc/JSTL3.html
  2. EL

Wicket est aussi une alternative qui sépare complètement java de html, ainsi un concepteur et un programmeur peuvent travailler ensemble et sur différents ensembles de code avec peu de compréhension les uns des autres.

Regardez Wicket.


Techniquement, les JSP sont tous convertis en Servlets pendant l'exécution . JSP a été initialement créé dans le but de découpler la logique métier et la logique de conception, en suivant le modèle MVC. Donc JSP sont techniquement tous les codes Java pendant l'exécution. Mais pour répondre à la question, les bibliothèques de balises sont généralement utilisées pour appliquer la logique (suppression des codes Java) aux pages JSP.


Si nous utilisons les éléments suivants dans une application web java, le code java peut être éliminé du premier plan de la JSP.

  1. Utiliser l'architecture MVC pour l'application Web

  2. Utiliser les balises JSP

    une. Tags standard

    b. Tags personnalisés

  3. Expression Language


Vous pouvez utiliser des balises JSTL avec des expressions EL pour éviter le mélange de code Java et HTML:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<html>
    <head>
    </head>
    <body>

        <c:out value="${x + 1}" />
        <c:out value="${param.name}" />
    // and so on

    </body>
</html>

En tant que sauvegarde: Désactiver les scriptlets pour le bien

Comme une autre question discute, vous pouvez et devez toujours désactiver les scriptlets dans votre web.xml d'application web web.xml .

Je ferais toujours cela afin d'empêcher tout développeur d'ajouter des scriptlets, en particulier dans les grandes entreprises où vous perdrez la vue d'ensemble tôt ou tard. Les paramètres web.xml ressemblent à ceci:

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

Une idée géniale du monde Python sont les langages d'attribut Template ; TAL a été introduit par Zope (donc "Zope Page Templates", ZPT) et est un standard, avec des implémentations en PHP, XSLT et Java aussi (j'ai utilisé les incarnations Python / Zope et PHP). Dans cette classe de langages de gabarit, un exemple ci-dessus pourrait ressembler à ceci:

<table>
    <tr tal:repeat="product products">
        <td tal:content="product/name">Example product</td>
        <td tal:content="product/description">A nice description</td>
        <td tal:content="product/price">1.23</td>
    </tr>
</table>

Le code ressemble à du HTML ordinaire (ou XHTML) plus quelques attributs spéciaux dans un espace de noms XML; il peut être visualisé avec un navigateur et être modifié en toute sécurité par un concepteur. Il y a un support pour les macros et pour i18n aussi:

<h1 i18n:translate="">Our special offers</h1>
<table>
    <tr tal:repeat="product products">
        <td tal:content="product/name"
            i18n:translate="">Example product</td>
        <td tal:content="product/description"
            i18n:translate="">A nice description</td>
        <td tal:content="product/price">1.23</td>
    </tr>
</table>

Si les traductions du contenu sont disponibles, elles sont utilisées.

Cependant, je ne connais pas très bien l' implémentation de Java .


L'expérience a montré que les JSP présentent certaines lacunes, l'une d'entre elles étant difficile à éviter en combinant le balisage avec le code réel.

Si vous le pouvez, pensez à utiliser une technologie spécialisée pour ce que vous devez faire. Dans Java EE 6, il y a JSF 2.0, qui fournit beaucoup de fonctionnalités intéressantes, y compris le collage de beans Java avec des pages JSF via l' #{bean.method(argument)} .


Bien sûr, remplacez <%! counter++; %> <%! counter++; %> <%! counter++; %> par une architecture producteur-consommateur d'événements, où la couche de gestion est informée de la nécessité d'incrémenter le compteur, elle réagit en conséquence et notifie les présentateurs afin qu'ils mettent à jour les vues. Un certain nombre de transactions de base de données sont impliquées, car à l'avenir nous aurons besoin de connaître la valeur nouvelle et ancienne du compteur, qui l'a incrémentée et dans quel but. Évidemment, la sérialisation est impliquée, puisque les couches sont entièrement découplées. Vous pourrez incrémenter votre compteur sur RMI, IIOP, SOAP. Mais seul le HTML est requis, ce que vous n'implémentez pas, puisqu'il s'agit d'un cas banal. Votre nouvel objectif est d'atteindre 250 incréments par seconde sur votre nouveau serveur E7, 64 Go RAM.

J'ai plus de 20 ans de programmation, la plupart des projets échouent avant le sextet: Réutilisabilité Replaçabilité OO-capacité Déboguabilité Testabilité La maintenabilité est même nécessaire. D'autres projets, menés par des personnes qui ne se préoccupaient que de la fonctionnalité, ont été extrêmement fructueux. De plus, la structure rigide des objets, implémentée trop tôt dans le projet, rend le code incapable d'être adapté aux changements drastiques dans les spécifications (alias agile).

Donc, je considère comme la procrastination l'activité de définition de «couches» ou de structures de données redondantes soit au début du projet, soit lorsque cela n'est pas spécifiquement requis.


Utilisez simplement le tag JSTL et l'expression EL.


Nothing of that is used anymore my friend, my advice is to decouple the view(css, html, javascript, etc) from the server.

In my case I do my systems handling the view with Angular and any data needed is brought from the server using rest services.

Believe me, this will change the way you design


L'utilisation de scriptlets (ces choses <% %> %% <% %> ) dans JSP est en effet fortement déconseillée depuis la naissance de taglibs (comme JSTL ) et EL ( EL , ces ${} choses) il y a plus de dix ans.

Les principaux inconvénients des scriptlets sont:

  1. Réutilisable: vous ne pouvez pas réutiliser les scriptlets.
  2. Remplaçabilité: vous ne pouvez pas rendre les scriptlets abstraits.
  3. OO-capacité: vous ne pouvez pas utiliser l'héritage / la composition.
  4. Débogage: si le scriptlet lève une exception à mi-chemin, tout ce que vous obtenez est une page blanche.
  5. Testabilité: les scriptlets ne sont pas testables à l'unité.
  6. Maintenabilité: par saldo il faut plus de temps pour maintenir la logique de code mêlée / encombrée / dupliquée.

Sun Oracle lui-même recommande également dans les conventions de codage JSP d'éviter l'utilisation de scriptlets lorsque la même fonctionnalité est possible avec des classes (tag). Voici plusieurs cités de pertinence:

A partir de la spécification JSP 1.2, il est fortement recommandé d'utiliser la bibliothèque de balises JSP standard (JSTL) dans votre application Web pour réduire le besoin de scriptlets JSP dans vos pages. Les pages qui utilisent JSTL sont, en général, plus faciles à lire et à maintenir.

...

Dans la mesure du possible, évitez les scriptlets JSP lorsque les bibliothèques de balises fournissent des fonctionnalités équivalentes. Cela facilite la lecture et la maintenance des pages, aide à séparer la logique métier de la logique de présentation et rendra vos pages plus faciles à évoluer vers des pages de style JSP 2.0 (la spécification JSP 2.0 prend en charge mais désaccentue l'utilisation de scriptlets).

...

Dans l'esprit de l'adoption du modèle de conception MVC (Model-View-Controller) pour réduire le couplage entre le niveau de présentation et la logique métier, les scriptlets JSP ne doivent pas être utilisés pour l'écriture de la logique métier. Au lieu de cela, les scriptlets JSP sont utilisés si nécessaire pour transformer les données (également appelées "objets de valeur") renvoyées à partir du traitement des requêtes du client dans un format adapté au client. Même alors, cela serait mieux fait avec une servlet de contrôleur frontal ou une étiquette personnalisée.

Le remplacement des scriptlets dépend entièrement du seul but du code / de la logique. Plus souvent, ce code doit être placé dans une classe Java complète:

  • Si vous voulez invoquer le même code Java sur chaque requête, plus ou moins indépendamment de la page demandée, par exemple vérifier si un utilisateur est connecté, puis implémenter un filter et écrire le code en conséquence dans la méthode doFilter() . Par exemple:

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
        if (((HttpServletRequest) request).getSession().getAttribute("user") == null) {
            ((HttpServletResponse) response).sendRedirect("login"); // Not logged in, redirect to login page.
        } else {
            chain.doFilter(request, response); // Logged in, just continue request.
        }
    }
    

    Lorsqu'il est mappé sur un <url-pattern> approprié couvrant les pages d'intérêt JSP, vous n'avez pas besoin de copier le même morceau de code sur toutes les pages JSP.

  • Si vous souhaitez appeler du code Java pour pré - traiter une requête, par exemple précharger une liste d'une base de données pour l'afficher dans une table, en fonction de paramètres de requête, implémentez une servlet et écrivez le code en conséquence dans la méthode doGet() . Par exemple:

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            List<Product> products = productService.list(); // Obtain all products.
            request.setAttribute("products", products); // Store products in request scope.
            request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response); // Forward to JSP page to display them in a HTML table.
        } catch (SQLException e) {
            throw new ServletException("Retrieving products failed!", e);
        }
    }
    

    Cette façon de traiter les exceptions est plus facile. La base de données n'est pas accessible au milieu du rendu JSP, mais bien avant que la JSP ne soit affichée. Vous avez toujours la possibilité de modifier la réponse chaque fois que l'accès à la base de données génère une exception. Dans l'exemple ci-dessus, la page d'erreur par défaut 500 s'affichera, que vous pouvez personnaliser de toute façon par une <error-page> dans le web.xml .

  • Si vous souhaitez appeler du code Java pour post -traiter une requête, par exemple traiter un formulaire, puis implémenter une servlet et écrire le code en conséquence dans la méthode doPost() . Par exemple:

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        User user = userService.find(username, password);
    
        if (user != null) {
            request.getSession().setAttribute("user", user); // Login user.
            response.sendRedirect("home"); // Redirect to home page.
        } else {
            request.setAttribute("message", "Unknown username/password. Please retry."); // Store error message in request scope.
            request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to JSP page to redisplay login form with error.
        }
    }
    

    Cette façon de traiter différentes destinations de pages de résultats est plus facile: réafficher le formulaire avec des erreurs de validation en cas d'erreur (dans cet exemple particulier, vous pouvez le réafficher en utilisant ${message} dans EL ), ou simplement accéder à la page cible souhaitée de succès.

  • Si vous souhaitez appeler du code Java pour contrôler le plan d'exécution et / ou la destination de la requête et la réponse, implémentez une servlet fonction du modèle de contrôleur frontal du MVC . Par exemple:

    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            Action action = ActionFactory.getAction(request);
            String view = action.execute(request, response);
    
            if (view.equals(request.getPathInfo().substring(1)) {
                request.getRequestDispatcher("/WEB-INF/" + view + ".jsp").forward(request, response);
            } else {
                response.sendRedirect(view);
            }
        } catch (Exception e) {
            throw new ServletException("Executing action failed.", e);
        }
    }
    

    Ou simplement adopter un framework MVC comme JSF , Spring MVC , Wicket , etc. pour que vous finissiez avec juste une page JSP / Facelets et une classe Javabean sans avoir besoin d'une servlet personnalisée.

  • Si vous souhaitez appeler du code Java pour contrôler le flux dans une page JSP, vous devez récupérer un taglib de contrôle de flux (existant) comme le noyau JSTL . Par exemple, afficher List<Product> dans une table:

    <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
    ...
    <table>
        <c:forEach items="${products}" var="product">
            <tr>
                <td>${product.name}</td>
                <td>${product.description}</td>
                <td>${product.price}</td>
            </tr>
        </c:forEach>
    </table>
    

    Avec des balises de style XML qui s'intègrent bien à tout ce HTML, le code est plus lisible (et donc plus facile à maintenir) qu'un tas de scriptlets avec différentes accolades ouvrantes et fermantes ( "Où le diable est-il attaché?" ). Une aide simple consiste à configurer votre application Web pour qu'elle lève une exception chaque fois que des scriptlets sont encore utilisés en ajoutant la partie suivante à web.xml :

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

    Dans Facelets , le successeur de JSP, qui fait partie du framework JSF Java MV fourni, il n'est déjà pas possible d'utiliser des scriptlets . De cette façon, vous êtes automatiquement obligé de faire les choses "dans le bon sens".

  • Si vous souhaitez invoquer du code Java pour accéder et afficher des données "backend" dans une page JSP, vous devez utiliser EL (Expression Language), ces choses ${} . Par exemple, réaffichage des valeurs d'entrée soumises:

    <input type="text" name="foo" value="${param.foo}" />
    

    Le ${param.foo} affiche le résultat de request.getParameter("foo") .

  • Si vous souhaitez appeler du code Java utilitaire directement dans la page JSP (généralement public static méthodes public static ), vous devez les définir en tant que fonctions EL. Il y a une fonction standard taglib dans JSTL, mais vous pouvez aussi créer facilement des fonctions vous-même . Voici un exemple de la manière dont JSTL fn:escapeXml est utile pour empêcher les attacks XSS .

    <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
    ...
    <input type="text" name="foo" value="${fn:escapeXml(param.foo)}" />
    

    Notez que la sensibilité XSS n'est en aucun cas spécifiquement liée à Java / JSP / JSTL / EL / quoi que ce soit, ce problème doit être pris en compte dans chaque application web que vous développez. Le problème des scriptlets est qu'il ne fournit aucun moyen de prévention intégrée, du moins en n'utilisant pas l'API Java standard. Le successeur de JSP Facelets a déjà un échappement HTML implicite, donc vous n'avez pas besoin de vous inquiéter des trous XSS dans Facelets.

Voir également:


JSP 2.0 a une fonctionnalité appelée "Tag Files" , vous pouvez écrire des balises sans code java externe et tld . Vous devez créer un fichier .tag et le mettre dans des WEB-INF\tags vous pouvez même créer une structure de répertoire pour emballer vos balises.

Par exemple:

/WEB-INF/tags/html/label.tag

<%@tag description="Rensders a label with required css class" pageEncoding="UTF-8"%>
<%@attribute name="name" required="true" description="The label"%>

<label class="control-label control-default"  id="${name}Label">${name}</label>

Utilisez-le comme

<%@ taglib prefix="h" tagdir="/WEB-INF/tags/html"%>
<h:label  name="customer name" />

Aussi, vous pouvez lire le corps de l'étiquette facilement

/WEB-INF/tags/html/bold.tag
<%@tag description="Bold tag" pageEncoding="UTF-8"%>
<b>
  <jsp:doBody/>
</b>

Utilise le

<%@ taglib prefix="h" tagdir="/WEB-INF/tags/bold"%>
<h:bold>Make me bold</h:bold>

The samples are very simple but you can do lots of complicated tasks here. Please consider you can use other tags (eg: JSTL which has controlling tags like if/forEcah/chosen text manipulation like format/contains/uppercase or even SQL tags select/update ), pass all kind parameters, for example Hashmap , access session , request , ... in your tag file too.

Tag File are so easy developed as you did not need to restart the server when changing them, like jsp files. This make them easy for development.

Even if you use a framework like struts 2, which have lots of good tags, you may find that having your own tags can reduce your code a lot. You can pass your tag parameters to struts and this way customize your framework tag.

You can use tag not only to avoid java but also minimize your HTML codes. I myself try to review HTML codes and build tags a lot as soon as see code duplicates start in my pages.

(Even if you end up using the java in you jsp code, which I hope not, you can encapsulate that code in a tag)


As many answers says, use JSTL or create your own custom tags. Here is good explanation about creating custom tags


Utilisez les JSTL Tag libraries dans JSP, cela fonctionnera parfaitement.


Comment éviter le code Java dans les fichiers JSP?

Vous pouvez utiliser des balises de bibliothèque d'onglets telles que JSTL en plus du langage d'expression ( EL ). Mais EL ne fonctionne pas bien avec JSP. Il est donc préférable de supprimer complètement JSP et d'utiliser Facelets .

Facelets est le premier langage de déclaration de page non JSP conçu pour JSF (Java Server Faces), qui a fourni aux développeurs JSF un modèle de programmation plus simple et plus puissant que JSP. Il résout différents problèmes rencontrés dans JSP pour le développement d'applications Web.


Assez simple

public class SomeClass{

    int number;
    String someString;

    public SomeClass(){
        number = 0;
    }

    public SomeClass(int number){
        this(); //set the class to 0
        this.setNumber(number); 
    }

    public SomeClass(int number, String someString){
        this(number); //call public SomeClass( int number )
    }

    public void setNumber(int number){
        this.number = number;
    }
    public void setString(String someString){
        this.someString = someString;
    }
    //.... add some accessors
}

Maintenant, voici un petit crédit supplémentaire:

public SomeOtherClass extends SomeClass {
    public SomeOtherClass(int number, String someString){
         super(number, someString); //calls public SomeClass(int number, String someString)
    }
    //.... Some other code.
}

J'espère que cela t'aides.





java jsp scriptlet