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()itoString().
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>
GO TO FULL VERSION