6.1 Wat zijn JavaBeans

Al eind jaren 90 begon de Java-taal actief te worden gebruikt voor grote servertoepassingen, waarbij het aantal klassen wordt gemeten in tien- en honderdduizenden. Toen ontstond het idee om het uiterlijk van Java-objecten te standaardiseren.

De hele Java-taal werd niet aangeraakt, om die niet aan flexibiliteit te ontnemen. Nou, achterwaartse compatibiliteit en zo. Vervolgens ontwikkelden ze een aantal criteria voor nieuwe generatie Java-objecten en noemden dergelijke objecten Java Beans. Java is vernoemd naar een populair koffiemerk, dus Java Beans vertaalt zich letterlijk naar "koffiebonen".

De belangrijkste criteria waren:

  • Toegang tot de interne velden van de klasse gaat via de getProperty().
  • Het schrijven van gegevens naar klassevelden gaat via de setProperty(value).
  • De klasse moet een openbare parameterloze constructor hebben .
  • De klasse moet serialiseerbaar zijn.
  • De klasse moet de methodes equals(), hashCode()en overschreven hebben toString().

Deze aanpak maakte de aanvragen minder samenhangend. Altijd duidelijk:

  • hoe een object te maken - er is een openbare standaardconstructor;
  • hoe de eigenschapswaarde te krijgen/in te stellen;
  • hoe een object over te dragen/op te slaan (we gebruiken serialisatie);
  • hoe objecten te vergelijken (met behulp van equals() en hashCode());
  • hoe informatie over het object in het logboek kan worden weergegeven (gebruik toString).

Nu is het eigenlijk de industriestandaard, maar het was ooit een nieuwe trend. Het lijkt erop dat iedereen al zo schrijft, maar als je je HttpClient en zijn bouwers herinnert, kun je zien dat de nieuwe standaard moeilijk is voor iemand.

Dergelijke objecten worden veel gebruikt wanneer hun belangrijkste semantische lading gegevensopslag is. Bijvoorbeeld in GUI's, databases en JSP-pagina's.

6.2 JSP's en JavaBeans

Een van de redenen voor de JSP was dat het kon worden uitbesteed aan front-end developers. En wat? Je hebt iemand die HTML begrijpt, laat hem JSP schrijven. Java-programmeurs schrijven hun deel, front-end-ontwikkelaars schrijven het hunne - alles is in orde.

En alles was in orde totdat de front-end-ontwikkelaars de geschreven Java-code die in de JSP was ingebed, moesten begrijpen. Of, nog erger, zelf zo'n code schrijven.

Java-programmeurs waren hier ook niet blij mee. Nou, zeg maar, welke lay-outontwerpers zijn backend-ontwikkelaars? Ja, ze kunnen niets anders schrijven dan scripts. Ja, en het hele programmeerparadigma zegt dat het mengen van verschillende talen in één bestand een slechte vorm is.

Toen kwam het idee naar eigen zeggen om front-end developers de mogelijkheid te geven om met Java-objecten te werken, net als met HTML-code. Elke HTML-tag is ook een object met zijn eigen velden. Waarom zou u niet op dezelfde manier met Java-objecten werken?

Zo gezegd zo gedaan. Speciale tags toegevoegd en weg zijn we.

Objectcreatie:

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

Dit commando creëerde een object met het type objecten plaatste het sessiononder de naam Name.

Objecten kunnen worden opgeslagen in een van de vier winkels: applicatie (globaal), sessie, verzoek en pagina. Het was ook mogelijk om een ​​eigenschap van dergelijke objecten in te stellen:

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

Je zou de eigenschap van dergelijke objecten als volgt kunnen krijgen:

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

Een voorbeeld van het gebruik van tags:

<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>