poniedziałek, 6 kwietnia 2009

Rozdział 2. Dużo szczegółów na temat wnętrzności Wicket

Rozdział drugi skupia się na zasadach działania Wicketa oraz założeniach jakie zostały przyjęte w trackie jego tworzenia. Rozdział ten, według autorów, można pominąć i wrócić do niego w miarę potrzeb. Sprawdźmy jednak, czy aby nie starają się ukryć czegoś ciekawego...
Za obsługę żądań w Wicket odpowiedzialne są 3 klasy: Application, Session i Request. Nie ma nic zaskakującego w przypadku Application - ot, każda aplikacja ma dokładnie jej jedną instancję, ale już dla Session Wicket ma ciekawą funkcjonalność. Mianowicie, nie jesteśmy już skazani na pamiętanie poszczególnych wartości w mapie dostarczanej przez HttpSession. Teraz mamy specjalizowane obiekty, które mogą być przechowywane w sesji. Wygląda to mniej więcej tak:

public class MySession extends WebSession {

private User user;

public static MySession get() {
return (MySession) Session.get();
}

public MySession(Request request) {
super(request);
}

public synchronized User getUser() {
return user;
}

public synchronized boolean isAuthenticated() {
return (user != null);
}

public synchronized void setUser(User user) {
this.user = user;
}
}

Warto zwrócić uwagę na to, że wszystkie metody są synchronized - sesje nie są "thread-safe".
When using Wicket, you typically never need to deal with the raw HttpServlet-
Request or Response objects; this holds true even when you’re dealing with custom
sessions.
Ponadto zostały omówione elementy takie jak SessionStore (odpowiedzialny za przechowywanie informacji o sesji oraz śledzenie historii przeglądanych przez użytkownika stron), Request, Response, RequestCycle, RequestCycleProcessor, RequestTarget. Nie staram się narazie zgłębić co poniektóre z nich tak naprawdę robią - myślę, że przyjdzie na to pora w dalszych rozdziałach jak przyjdzie do kodowania.
W kolejnym podrozdziale omówione zostały komponenty w Wicket. Podsumowując, Wicket daje możliwość stworzenia własnych komponentów. Każdy taki komponent musi dziedziczyć po Component, posiadać model oraz sposób prezentacji. Autorzy podają kilka cech komponentów:
  • Są niezależne i samowystarczalne - jeżeli chcemy użyć jakiegokolwiek komponentu wystarczy go umieścić na stronie. Inne komponenty nie muszą wiedzieć nic na jego temat.
  • Nadają się do ponowego użycia.
  • Można je stworzyć wykorzystując czystą Javę.
  • Żeby je wykorzystać również możemy posłużyć się tylko i wyłącznie językiem Java.
W dalszej części autorzy zagłębiają się w zagadnienia związane z łączeniem widoku (markup) z klasami oraz zagnieżdzaniem komponentów na stronie. Myślę, że temat ten sam wyjaśni się w miarę zdobywania wiedzy z kolejnych rozdziałów. Ewentualnie powrócę do tego podrozdziału później.
Jednym z ostatnich tematów poruszanych w rozdziale 2 są rozważania na temat rozdzielenia logiki i prezentacji. Wicket wymusza na nas takie podejście. Używając Wicketa nie ma prawa dojść do sytuacji, w której w widoku mamy pętle, instrukcje warunkowe itp. Autorzy wymieniają wiele zalet tego podejścia, ale najważniejszy chyba jest fakt, że tak naprawdę wiadomo gdzie tej logiki szukać. Ponadto takie podejście daje większe szanse na ponowne użycie kodu. Poza tym nie wiem jak Wy, ale ja nigdy nie przepadałem za specyficzną formą np. JSP.
Dalej zostały omówione zagadnienia związane z modelem, które szczerze mówiąc pominąłem oraz interfejs IBehavior pozwalający na dodawanie zachowań do komponentów. Dzięki temu jeżeli chcemy stworzyć link służący do usunięcia pozycji koszyka, który po kliknięciu wyświetli komunikat potwierdzający ten fakt, wcale nie musimy tworzyć nowej klasy dziedziczącej po Link i dodającej tę funkcjonalność. Właśnie w tym celu można dodać nowe zachowanie dla wybranego komponentu.
Podsumowując rozdział drugi to bardzo duża dawka wiedzy teoretycznej, która dla osoby zaczynającej przygodę z Wicket może być ciężkastrawna. Myślę, że w miarę poznawania kolejnych rozdziałów wiele zagadnień będzie się wyjaśniało.
Przekartowałem rozdział 3 - długi, dużo kodu i wygląda interesująco. Wkrótce relacja.

Brak komentarzy: