6.1 Czym są komponenty JavaBeans

Już pod koniec lat 90-tych język Java zaczął być aktywnie wykorzystywany w dużych aplikacjach serwerowych, gdzie ilość klas mierzona jest w dziesiątkach i setkach tysięcy. Wtedy pojawił się pomysł ujednolicenia wyglądu obiektów Java.

Nie ruszano całego języka Java, aby nie pozbawić go elastyczności. Cóż, wsteczna kompatybilność i tak dalej. Następnie opracowali szereg kryteriów dla obiektów Java nowej generacji i nazwali takie obiekty Java Beans. Nazwa Java pochodzi od popularnej marki kawy, więc nazwa Java Beans dosłownie oznacza „ziarna kawy”.

Najważniejszymi kryteriami były:

  • Dostęp do wewnętrznych pól klasy przechodzi przez getProperty().
  • Zapisywanie danych w polach klas przechodzi przez setProperty(value).
  • Klasa musi mieć publicznego konstruktora bez parametrów .
  • Klasa musi być serializowalna.
  • Klasa musi mieć nadpisane metody equals(), hashCode()i toString().
Java university

Takie podejście powodowało, że aplikacje były mniej spójne. Zawsze jasne:

  • jak stworzyć obiekt - istnieje publiczny domyślny konstruktor;
  • jak uzyskać/ustawić wartość właściwości;
  • jak przenieść/zapisać obiekt (używamy serializacji);
  • jak porównywać obiekty (za pomocą equals() i hashCode());
  • jak wyświetlić informacje o obiekcie w logu (użyj toString).

Teraz jest to właściwie standard branżowy, ale kiedyś był to nowy trend. Wydaje się, że wszyscy już tak piszą, choć jeśli pamiętacie HttpClient i jego Buildery, to widać, że nowy standard jest dla kogoś trudny.

Takie obiekty są szeroko stosowane tam, gdzie ich głównym obciążeniem semantycznym jest przechowywanie danych. Na przykład w interfejsach GUI, bazach danych i stronach JSP.

6.2 JSP i komponenty JavaBeans

Jednym z powodów JSP było to, że można go zlecić programistom front-end. I co? Masz osobę, która rozumie HTML, niech napisze JSP. Programiści Java piszą swoją część, programiści front-end dopisują swoją - wszystko jest w porządku.

I wszystko było dobrze, dopóki programiści front-end nie musieli zrozumieć napisanego kodu Java osadzonego w JSP. Lub, co gorsza, sam napisz taki kod.

Programiści Javy również nie byli z tego zadowoleni. Cóż, módlcie się, powiedzcie, którzy projektanci układu są programistami zaplecza? Tak, nie mogą pisać niczego poza skryptami. Tak, a cały paradygmat programowania mówi, że mieszanie różnych języków w jednym pliku to zła forma.

Wtedy pojawił się pomysł, aby dać programistom front-end możliwość pracy z obiektami Java, tak jak z kodem HTML. Każdy tag HTML jest również obiektem z własnymi polami, dlaczego nie pracować z obiektami Java w podobny sposób?

Nie prędzej powiedziane niż zrobione. Dodano specjalne tagi i ruszamy.

Tworzenie obiektów:

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

To polecenie utworzyło obiekt o typie objecti umieściło go sessionpod nazwą Name.

Obiekty mogły być przechowywane w jednym z czterech magazynów: aplikacja (globalna), sesja, żądanie i strona. Możliwe było również ustawienie właściwości takich obiektów:

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

Możesz uzyskać właściwość takich obiektów w następujący sposób:

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

Przykład użycia tagów:

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