Swinguj z nami czyli piszemy aplikację cz.2

Po kilku miesiącach od pierwszego wydania przyszła kolej na krok dalej – oto druga wersja klienta do gry w Arkadię, opartego na Swingu i mojej niedostatecznej znajomości Javy :)

Przyznaję, że wydanie to mogłoby pojawić się wcześniej. Jednakże wpierw mały romans z JEE, a potem wypadki losowe odwlekły ten fakt w czasie. Przez kilkanaście ostatnich dni przysiadłem fałdów i oto jest – druga wersja ChlebikClient. Wiele jeszcze jej brakuje do optymalnego funkcjonowania jako wymarzony klient, jednakże widać już pewne zarysy jak mogłaby wyglądać taka aplikacja, kiedy bierze się za nią newbies. Jednakże postanowiłem, że wydanie drugie będzie również i ostatnim – gdyż kolejne wydania byłyby po prostu dokładaniem bardzo podobnych do obecnych cegiełek. Czyli kolejny JInternalFrame, kolejny plik XMLa i tak dalej – ani to wiele już nie rozwija, a i sensowności dalszej w tym nie ma zbyt wiele.

Popracowałem z NetBeansem używając jego pomocy do tworzenia GUI, mam mniej więcej pojęcie o wątkach aplikacji pisanej w Swingu (choć i tak niewiele jak znam życie), operowanie podstawowe na plikach XML, poszczególne komponenty też obejrzałem sobie z kilku stron. Na dzień dzisiejszy dalsze prace zostają wstrzymane i odłożone na czasy obfitujące w wolny czas (może kiedyś nadejdą). Póki co zapraszam na podstronę projektu, gdzie można przeczytać listę zmian oraz ściągnąć najnowszą wersję.

Co zaś do przyszłości – zmierzam w kierunku JEE. Dla nauki rozpoczynam pisanie aplikacji internetowej. Wstępnie technologie użyte to JSP, Hibernate/JDBC, wszystko zapakowane w Tomcata. Być może tym razem spróbuję użyć do pracy Eclipse’a wraz z jego rozszerzeniem WTP.

JSF i dlaczego jestem zdumiony

Jak wspomniałem w jednym z poprzednich wpisów nabyłem trochę ciekawych książek o wiadomym temacie. No i po tym jak ‘prześlizgnąłem się’ po Head-First JSP i Servlety zabrałem się od razu za Core JSF. I ZONK! Po raz kolejny podejście wzięte z PHP sprawiło, że uderzyłem o ścianę. Ale tym razem cholera miało być inaczej.

Tok mego rozumowania był prosty – mamy JSP i serwlety. Służy to do pisania aplikacji webowych dla platformy JEE (nie całych, ale na pewno widoku i kontrolera). Znaczy się może służyć, bo wiadomym jest, że dzisiaj raczej w czystych językach nikt nie pisze – używa się różnych bibliotek i komponentów, których połączenie często okazuje się na tyle fajne, że powstaje framework. I takie coś mamy w PHP – język językiem, no ale w okolicy wersji 5.1 kiedy to OOP przestało być czymś na papierze, a stało się rzeczywistością pojawiły się pierwsze frameworki. Kiedy rozpoczynałem pracę jako koder PHP dostałem się w szpony Zend Frameworka i wciąż w nich tkwię. Po drodze bawiłem się trochę Symphony, a także RORem (choć to inny język). Dla mnie zatem framework to zestaw przynajmniej gotowych komponentów, które rutynowe czynności w budowie aplikacji sprowadzają do inicjalizacji kilku obiektów i wywołania ich metod. To co potrafi momentami Symphony czy ROR to już w ogóle kosmos i nic dziwnego, że ludzie tego używają.

Wracając do Javy – myślałem, że JSP to takie PHP, no a JSF to framework, czyli liznę tego pierwszego na razie byle się tylko orientować, przepatrzę książkę o JSFie i wezmę się za pisanie projektu łączącego tę wiedzę w jednym. Może to wina książki, albo i samego narzędzia. Jednakże załamało mnie to, iż po lekturze 100 stron to wiem na pewno, że wszystko o czym czytam zostanie omówione w następnych rozdziałach. No nic, przepatruję z ciekawości spis treści. Przerobiłem na chwilę obecną wstęp, coś o beansach, rozdzialik o nawigacji (XML rządzi) i zacząłem znaczniki standardowe. Zostaje mi rozdział o znacznikach niestandardowych, weryfikacji danych, obsłudze zdarzeń i… w sumie nic. Bo następne rozdziały to niestandardowe elementy, potem JDBC/LDAP, AJAX no i omówienie bardzo pokrótkie inych frameworków!!! Na koniec mam rozdział zatytułowany ‘Jak to zrobić?’. Mam pomysł by na tym pytaniu oprzeć ćwiczeniowy projekt pisany w JSP (aplikacji internetowej) zatem przerzuciłem te 400 stron i wziąłem się za szybkie przeglądanie rozdziału. ZONK!

Rozbiło mnie już pytanie trzecie (sic!) na łącznie około 35. Jak zaimplementować obsługę wysyłania plików na serwer?. O nareszcie coś z bliskich mi klimatów. Dla niezorientowanych w temacie PHP wyjaśniam – w tym języku jest to kwestia sprawdzenia czy przesłano element “file” z formularza, po czym sprawdza się czy plik doszedł i zapisuje się go w docelowym katalogu. W wersji spartańskiej robi się to może 5 linijkami kodu (wliczając po nawiasach klamrowych na linię). W Zend Frameworku mam do tego jego element w postaci Zend_File, a w nim cuda niewidy – walidatory, filtry, plus adaptery dla wysyłania plików. Można to łatwo zobaczyć – kilka linii kodu i działamy.

A co mamy w JSF? Chwilka, już liczę… Serwlet filtrujący (109 linii kodu) plus klasa renderująca (89 linii) plus klasa dla znacznika ( 28 linii ) plus sam plik JSP ( 18 linii ), ale to można pominąć. Szybkie dodawanie i okazuje się, że by wysłać plik na serwer i wiedzieć, że dotarł cały i bezpieczny muszę sklepać ponad 200 linii kodu!!! Cholera no to jest framework czy jakiś #$@#@%^^%? Jak można nazywać taką technologię frameworkiem, skoro zamiast usprawniać tworzenie aplikacji niewiele ona w sobie zawiera? No niby co poza jasno określonym MVC (ale przecież JSP też to ma, a tu jeszcze od cholery XMLa na ścieżki nawigacji), pomocą z renderowaniem widoku (View) czy w końcu znacznikami JSF technologia ta może zaoferować?

Ufff, przepraszam, uniosłem się, to był przedostatni raz. Naprawdę zaczynam rozumieć, dlaczego w ogłoszeniach o pracę dla javowców wymienia się po 4 elementy z każdej dziedziny (Struts, Spring, JSF, Ant, Maven, Hiberante, TopLink, iBATIS, JBoss, WebSphere, Tomcat). Nie wiem, ja generalnie młody jestem, zaczynam bawić się w te klocki, ale błagam, niech ktoś mi powie: “potem będzie lepiej”. Framework będzie frameworkiem z zapleczem, a nie tylko ulepszonymi grabiami czy łopatą. Proszę niech ktoś powie: “młody jesteś, ucz się dalej”. Jak już poznasz to zrozumiesz.

Proszę :)

Java Server Pages i servletowe podwórko

Wspomniałem już przy okazji poprzedniego wpisu o serwletach oraz o technologii Java Server Pages. W dużym skrócie – serwlety to po prostu aplikacje Javy wykonywane po stronie serwera, zaś JSP to technologia umożliwiająca dynamiczne generowanie dokumentów (X)HTML poprzez osadzenie w kodzie HTMLa wstawek z języka Java (za Wikipedią). Dodatkowo rzecz z automatu jest realizowana we wzorcu MVC (Model-View-Controller), co można ostatecznie podsumować stwierdzeniem, że mamy bardzo przyjemne narzędzie do tworzenia aplikacji internetowych.

Dlaczego o tym piszę? Albowiem jako programista PHP pracujący nad projektami o bardzo pojemnej nazwie ‘webdevelopment’ automatycznie kieruję się w stronę znanych mi rozwiązań, a za takowe JSP (i potem Java Server Faces – to framework) można uznać. Jednoczesne poznawanie Javy (za pomocą Bruce’a Eckela i jego ‘Thinking in Java’) oraz JSP (książka ‘Head First JSP’) póki co okazało się dość obiecującym rozwiązaniem, gdyż zamiast klepać standardowe do bólu System.out.println i zachwycać się rozbudowaną konwersacją z konsolą, można tworzyć kod wypełniając znany sobie szkielet aplikacji (np. tworząc system blogowy).

Do rozpoczęcia zabawy z JSP potrzebujemy jednej rzeczy – kontenera na serwlety. Rolę tę pełni świetnie Apache, kiedy doinstaluje się do niego odpowiedni moduł, albo też kiedy zainstaluje się Apache Tomcat jako samodzielny serwer (www + jsp w jednym). Zasadniczo wyszedłem od tej koncepcji (czy wspominałem już, że jestem leniwy jeśli chodzi o babranie się z administracją?), a następnie spróbowałem jakoś to wrzucić (pluginem oczywiście) pod Eclipse’a. Po strawieniu 3h nad konfigiem oraz próbą zmuszenia tej aplikacji by w końcu zobaczyła mój plugin do Tomcata dałem za wygraną i postanowiłem ściągnąć NetBeans. Downloaded, zainstaluj, uruchom, ściągnij update i viola!!! Nagle okazało się, że wystarczy stworzyć nowy projekt i nacisnąć ‘Build all’ – wszystko pięknie śmiga. Jako, że była gdzieś 3 nad ranem porzuciłem zabawę, ale wróciłem do niej zaraz następnego dnia.

NetBeans ma to do siebie, że można go ściągnąć w kilku wersjach. Bardzo ważne jest to, że możemy również wybrać wersję niejako ‘out of the box’, gdyż razem z IDE dostarczany jest też Tomcat oraz GlassFish (to serwer aplikacji J2EE firmy Sun). Po zainstalowaniu otrzymujemy (pod Windowsem oczywiście) w pełni skonfigurowane narzędzie. Tutaj właśnie uwaga – opiszę co i jak by skonfigurować pierwszy projekt i uruchomić go. W książce ‘Head First JSP’ przedstawiono podział na 2 środowiska – developerskie oraz aplikacyjne (czyli produkcyjne). Jest to rozwiązanie poniekąd słuszne, jednakże na czas nauki, kiedy człowiek musi przypominać sobie czasem składnię podstawowych funkcji, jakoś nie widzę ku temu sensu.

W NetBeans zatem skonfigurujemy projekt tak, aby dało się w obrębie jednego katalogu jednocześnie posiadać kod źródłowy, jak i widzieć go (po kompilacji oczywiście) z poziomu przeglądarki. Oto co trzeba zrobić:

1. Okienko z projektami -> prawy przycisk myszy i oczywiście New Project
2. Pokazuje się lista do wyboru, nas interesuje Web, a potem Web Application
3. Nadajemy projektowi nazwę, NetBeans automatycznie poda domyślną ścieżkę do niego (czyli katalog webapps w katalogu gdzie zainstalowano Tomcata).
4. Pojawią się informacje o używanej wersji serwera i takich tam – wybieramy oczywiście to, co zainstalowane (najprawdopodobniej Tomcat 6.0, Java EE 5).
5. W następnym kroku mamy możliwość wyboru używanego frameworka. Jako, że nic takiego na razie nie ma miejsca, to klikamy Finish i mamy gotowy szkielet projektu.

By przetestować działanie całości należy prawym przyciskiem myszy kliknąć na nasz projekt (w okienku projektów) i wybrać Build. NetBeans nam pokompiluje co trzeba i następnie znowu pod prawym przyciskiem wybieramy Run i po paru sekundach mielenia otwiera się nam przeglądarka i pojawia się śliczne ‘Hello wordl!’ (adres to http://localhost:8084/TWOJANAZWAAPLIKACJI/).

Teraz kiedy już mamy działający projekt trzeba objaśnić trochę strukturę katalogów. Różni się ona od przyjętej w ‘Head First’, zatem dla jasności napiszę co i gdzie. Struktura katalogów w folderze naszej aplikacji wygląda tak:

1. Katalog nbproject to internalsy NetBeans i nie należy tego na razie dotykać.
2. Podobnie rzecz ma się ze znajdującym się w katalogu aplikacji plikiem build.xml oraz katalogiem dist – to informacje na temat sposobu budowania projektu, a w katalogu z kolei umieszcza się ostatecznie przygotowaną paczkę z kodem (w formie pliku *.war).
3. Katalog test służy zgodnie z nazwą do testów (testów jednostkowych opartych na JUnit)
4. W katalogu build zgodnie z nazwą budowany jest cała aplikacja
5. W katalog src znajduje się nasz kod źródłowy
6. I na sam koniec w folderze web znajdują się nasze pliki *.jsp i *.html (wraz z plikiem web.xml).

Oczywiście normalnie nikt nie będzie grzebał bezpośrednio w plikach w tym folderze – od tego jest IDE. Jednakże dobrze wiedzieć co i z czym, zwłaszcza dla początkujących informacja ta może być dość istotna. Nasz projekt póki co nie zawiera kodu Javy, ale jest w pełni gotowy na jego przyjęcie. Na razie rzut oka na okienko IDE:

Aplikacja na razie jest dla nas interesująca w dwóch miejscach. Pierwszym z nich jest katalog Source Packages. Tutaj należy dodawać kolejne pakiety, a w nich klasy (np. com.wordpress.chlebik.TestowaKlasa.java). Umieszczone tutaj zostaną w procesie budowania projektu skompilowane i przerobione na postać strawną dla serwera. Drugim ważnym katalogiem jest katalog web, gdzie znajduje się cały HTMLowy lub JSPowy kod. Dla przykładu – znajdź w tymże folderze plik index.jsp i zmień jego nazwę na np. index2.jsp. Teraz w przeglądarkę wrzuć adres http://localhost:8084/WebApplication1/. I co? Ano nic, błąd. Ale z kolei wpisanie http://localhost:8084/WebApplication1/index2.jsp już jak najbardziej działa. Na prostym przykładzie widać, co gdzie i z czym jeśli chodzi o HTML i JSP. W katalogu tym można również odnaleźć podkatalog WEB-INF gdzie znajduje się plik web.xml, który służy do (powiedzmy uogólniając) kierowania routingiem w naszej aplikacji. Jednakże to uczący się JSP już raczej wiedzą i nie potrzeba tego tematu rozwijać.

Mam nadzieję, że to krótkie i pewnie trochę chaotyczne wypociny jednakże komuś pomogą, a i może skłonią do sięgnięcia po NetBeans.