6.1 Que sont les JavaBeans

Déjà à la fin des années 90, le langage Java a commencé à être activement utilisé pour les grandes applications serveur, où le nombre de classes se mesure en dizaines et en centaines de milliers. C'est alors que l'idée de standardiser l'apparence des objets Java est née.

L'ensemble du langage Java n'a pas été touché, afin de ne pas le priver de souplesse. Eh bien, la rétrocompatibilité et tout ça. Ensuite, ils ont développé un certain nombre de critères pour les objets Java de nouvelle génération et ont appelé ces objets Java Beans. Java tire son nom d'une marque de café populaire, donc Java Beans se traduit littéralement par "grains de café".

Les critères les plus importants étaient :

  • L'accès aux champs internes de la classe passe par le getProperty().
  • L'écriture de données dans des champs de classe passe par le setProperty(value).
  • La classe doit avoir un constructeur public sans paramètre .
  • La classe doit être sérialisable.
  • La classe doit avoir les méthodes equals(), hashCode()et remplacées toString().
Java webinar

Cette approche a rendu les demandes moins cohérentes. Toujours clair :

  • comment créer un objet - il existe un constructeur public par défaut ;
  • comment obtenir/définir la valeur de la propriété ;
  • comment transférer/sauvegarder un objet (nous utilisons la sérialisation) ;
  • comment comparer des objets (en utilisant equals() et hashCode());
  • comment afficher des informations sur l'objet dans le journal (utilisez toString).

Aujourd'hui, c'est en fait la norme de l'industrie, mais c'était autrefois une nouvelle tendance. Il semble que tout le monde écrive déjà comme ça, bien que si vous vous souvenez de HttpClient et de ses constructeurs, vous pouvez voir que la nouvelle norme est difficile pour quelqu'un.

De tels objets sont largement utilisés là où leur principale charge sémantique est le stockage de données. Par exemple, dans les interfaces graphiques, les bases de données et les pages JSP.

6.2 JSP et JavaBeans

L'une des raisons de la JSP était qu'elle pouvait être sous-traitée à des développeurs front-end. Et quoi? Vous avez une personne qui comprend le HTML, laissez-le écrire JSP. Les programmeurs Java écrivent leur part, les développeurs front-end écrivent la leur - tout va bien.

Et tout allait bien jusqu'à ce que les développeurs front-end aient à comprendre le code Java écrit intégré dans le JSP. Ou, pire encore, écrivez vous-même ce code.

Les programmeurs Java n'étaient pas satisfaits de cela non plus. Eh bien, dites-moi, quels concepteurs de mise en page sont des développeurs backend ? Oui, ils ne peuvent rien écrire sauf des scripts. Oui, et tout le paradigme de la programmation dit que mélanger différentes langues dans un seul fichier est une mauvaise forme.

Puis est venue l'idée selon eux de donner aux développeurs front-end la possibilité de travailler avec des objets Java, comme avec du code HTML. Chaque balise HTML est également un objet avec ses propres champs, pourquoi ne pas travailler avec des objets Java de la même manière ?

À peine dit que c'était fait. Ajout de balises spéciales et c'est parti.

Création d'objet :

<jsp:useBean id="Name" class="Object type" scope="session"/>

Cette commande a créé un objet avec le type objectet l'a placé sessionsous le nom Name.

Les objets peuvent être stockés dans l'un des quatre magasins suivants : application (global), session, requête et page. Il était également possible de définir une propriété de tels objets :

<jsp:setProperty name="Name" property="propName" value="string constant"/>

Vous pourriez obtenir la propriété de tels objets comme ceci :

<jsp:getProperty name="Name" property="propName"/>

Exemple d'utilisation de balises :

<body>
    <center>
        <h2>Using JavaBeans in JSP</h2>
        <jsp:useBean id = "test" class = "com.example.TestBean" />
        <jsp:setProperty name = "test" property = "message" value = "Hello JSP..." />
        <p> What-to do important</p>
        <jsp:getProperty name = "test" property = "message" />
    </center>
   </body>