Xoft

Naszym celem jest utworzenie prostej aplikacji szukającej plików na dysku, gotową aplikację można uruchomić przez Java WebStart, dostępny jest oczywiście kod źródłowy, powiedzmy, że na licencji BSD ;).

Wstęp
Swing Application Framework jest szkieletem aplikacyjnym, który ma uprościć tworzenie aplikacji desktopowych w Java Swing. SAF z założenia ma być rozwiązaniem prostym, rozwiązującym podstawowe problemy, na jakie napotykamy się tworząc programy z interfejsem użytkownika w Javie.

Czym więc zajmuje się SAF?

• Cyklem życia aplikacji od jej uruchomienia po zamknięcie
• Zarządzaniem zasobami: łańcuchami znaków, kolorami, ikonami, czcionkami itp. rzeczami, które występują w typowej aplikacji. Oczywiście wszystkie zasoby mogą być internacjonalizowane/lokalizowane.
• Obsługą zdarzeń (co ma się stać, gdy użytkownik naciśnie przycisk X). W szczególności SAF upraszcza znacząco obsługę długotrwałych zdarzeń, które powinny wykonywać się w wątkach roboczych, a nie głównym
• Pamiętaniem stanu aplikacji. Po zamknięciu aplikacji pamięta ona jaki był stan interfejsu użytkownika (rozmiar okien, ich położenie) przed zamknięciem.

Żeby nie przedłużać wstępu przejdźmy do rzeczy, czyli przyjrzyjmy się przykładowej aplikacji Szukacz. Szukacz jest kulawą i ubogą namiastką grep-a napisaną w Javie, ma za to graficzny interfejs użytkownika.

Aplikacja jest skonstruowana inaczej niż w większości tutoriali Swing Application Framework, które można znaleźć w Internecie. Problem z umieszczonymi tam przykładami jest taki, że w rzeczywistej sytuacji są one mało użyteczne. Przykłady te dzielą się na dwie grupy:

1. aplikacje wyklikane od początku do końca w środowisku NetBeans, korzystające z kreatorów kodu tam dostępnych
2. aplikacje napisane całkowicie ręcznie, włącznie z elementami GUI

Tak na prawdę żadna z tych sytuacji nie jest typowa.

Ad. 1. Nie każdy musi chcieć używać NetBeansa (fakt, jest bardzo dobry jeśli chodzi o tworzenie GUI), a nawet jeżeli używamy go, to istnieje duża szansa, że mamy już napisany jakiś spory kawał kodu, który nie używa SAF i chcielibyśmy jakoś gładko istniejący kod zintegrować z tym frameworkiem.

Ad. 2. Jeśli nie jesteśmy maniakalnymi zwolennikami ręcznego dziergania kodu GUI, co zazwyczaj kończy się mniejszą lub większą katastrofą połączoną z gromami rzucanymi na Swinga i Javę w ogóle, to pewnie chcemy użyć jakiegoś wizulanego narzędzi, które pozwoli nam wyklikać strukturę GUI. Narzędzie to na bank nie słyszało jeszcze o SAF, a my chcemy sobie klikać interfejs użytkownika i jednocześnie łatwo go zintegrować z SAF.

Tak więc chcę pokazać, jak tworzyć sobie GUI takim sposobem, jak nam się podoba i móc go w każdej chwili zintegrować z SAF. Zatem do dzieła. Czytaj resztę wpisu »

Wygląda na to, że są to dwaj najpopularniejsi gracze na rynku darmowych ajaksowych komponentów JSF, co zatem wybrać? Pierwsza rzecz: czy trzeba w ogóle wybierać? Niestety tak, obie biblioteki nie chcą ze sobą współpracować – każda z nich inaczej włącza się w cykl życia strony JSF i to powoduje różna zabawne problemy. Podobno w którejś tam wersji ma być możliwa koegzystencja obu produktów…

Porównanie obu bibliotek można znaleźć na stronie JSF Matrix, ale niewiele z niego wynika, jak to zazwyczaj bywa ze statystykami w rodzaju “liczba dostępnych komponentów”.

Kto i co robi
Zacznijmy od krótkiego przedstawienia obu bibliotek.

RichFaces. Biblioteka była produktem firmy Exadel, która połączyła się, albo została kupiona przez JBoss-a, czyli RedHata. Ehh, ten świat wielkich korporacji… Biblioteka jest dostępna na licencji Open Source, zawiera ponad 50 różnych komponentów JSF.

ICEFaces jest robiona przez firmę ICESoft i też jest opensorsowa.

Zalety RichFaces i wady ICE Faces
Dużą zaletą RichFaces jest pod-biblioteka Ajax4JSF, która pozwala “zajaksować” dowolny komponent JSF. Jest to bardzo wygodne, jeżeli mamy już napisany kawałek aplikacji i chcemy gdzieniegdzie ją upiększyć ajaksowymi wodotryskami.

Kolejną przyjemną cechą RichFaces jest możliwość określenia zachowania komponentów tak, żeby niekoniecznie za każdym razem łączyły się z serwerem (Ajaxa im można wyłączyć, innymi słowy). Można na przykład utworzyć stronę z zakładkami w ten sposób, że wszystkie są od razu ładowane i przy ich zmianie nie jest potrzebny kontakt z serwerem. Oczywiście można także skonfigurować sobie zachowanie ajaksowe, czyli zakładki będą doładowywane dynamicznie.

ICEFaces czegoś takiego nie potrafi, jego komponenty zawsze kontaktują się z serwerem, co jest trochę głupie w przypadku dajmy na to komponentu kalendarza – można go przecież zrobić łatwo po stronie klienta, każdorazowy kontakt z serwerem jest w 95% przypadków zbędny. Swoją drogą to jakaś obsesja, większość komponentów kalendarzowych ludzie robią ajaksem, tak przynajmniej mówi jsfmatrix.net.

ICEFaces pozwala używać JSF 1.2, ale wymaga używania trybu zgodności ze specyfikacją JSF 1.1. Trochę lipa.
W web.xml trzeba deklarować użycie starej wersji JavaServelts

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

a w faces-config.xml:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

Przez to nie możemy wykorzystać różnych fajnych rzeczy, które wniosło JSF 1.2.

Łatwiej jest testować aplikacje, które używają RichFaces, bo JSFUnit wspiera właśnie to rozwiązanie – nic w tym dziwnego, gdyż JSFUnita robi RedHat.

Zalety ICE Faces i wady RichFaces
Ok, wygląda na to, że RichFaces wygląda lepiej, ale parę rzeczy w ICE też mi przypadło do gustu. Przede wszystkim wygląd, komponenty są na prawdę dopracowane, wyglądają perfekcyjnie.

Druga rzecz, to sposób odświeżania strony JSF. ICE robią aktualizację wszystkich elementów ajaksowych na całej stronie, dzięki czemu nie musimy się martwić o synchronizację obsługi różnych żądań ajaksowych. W RichFaces trzeba to robić ręcznie, co ma swoje wady.

ICEFaces mają lepiej działającą obsługę ajaksa w trybie “push”, RichFaces też to potrafią, ale stosunkowo od niedawna, więc ciężko stwierdzić, na ile ich implementacja działa niezawodnie.

No i wreszcie na koniec ICEFaces dobrze integrują się nie tylko z Eclipse, ale także z NetBeansem (dla mnie to ważne, bo coraz częściej używam tego drugiego).

Decyzja?
Póki co, zdecydowanie RichFaces.