j2ee.pl - związani z javą » Inne biblioteki

Exadel Flamingo

Dariusz Sot — Fri, 12 Dec 2008 13:00:05 +0000

Ostatnimi czasy można zauważyć rosnącą popularność aplikacji typu RIA. Istnieje wiele technologii służących do tworzenia takich aplikacji – najważniejsze z nich to Adobe Flex oraz JavaFX. O ile pierwsza z nich ma już swoją pozycję na runku, to o drugiej jeszcze nie słychać zbyt dużo w kontekście portalowych stron WWW.

Jak wiadomo, w przypadku nowych technologii zawsze najtrudniejszy jest ten ‘pierwszy krok’:

jak skonfigurować środowisko?
jak stworzyć szkielet projektu?
jak to wszystko spiąć żeby dobrze działało?

Na wszystkie powyższe pytania i problemy jest jednak prosta i szybka odpowiedź: Exadel Flamingo.

Na problemy – Flamingo

Flamingo to zestaw bibliotek i komend służących jako pomoc w wygenerowaniu i konfiguracji szkieletu aplikacji typu RIA. Obsługa generatora Flamingo jest bardzo prosta. Polega na odpowiedzi na kilka pytań zadawanych w formie wizarda – na ich podstawie jest generowany odpowiedni projekt. Flamingo bazuje na Mavenie i każdy wygenerowany projekt jest w tej konwencji. Dzięki temu bardzo prosto można odnaleźć się w projekcie – oczywiście dla ludzi znających tą konwencję, ale chyba w dzisiejszych czasach znajomość Mavena jest raczej powszechna ;-)

Wygenerowany kod szkieletu posiada pełne wsparcie i jest skonfigurowany do pracy pomiędzy Flexem lub JavąFX a JBoss Seamem lub Springiem. Każdy znajdzie więc coś dla siebie, gdyż Seam to raczej podstawowa sprawa jeżeli chodzi o aplikacje EJB3, a Spring – to już klasyka. Wybór jest więc zatem ograniczony do najbardziej popularnych aktualnie technologii i oznacza, że w ogromnej większości przypadków takiego ograniczenia nie trzeba sztucznie obchodzić.

Wygenerowany szkielet jest naprawdę kompletny, Flamingo zajmuje się tutaj wszystkim:

generuje odpowiednie klasy (klasę) odpowiedzialne za (bardzo prosty) model danych
generuje warstwy aplikacji, włączając w to serwisy oraz DAO oraz konfiguruje całą komunikację, począwszy od interfejsu użytkownika a kończąc na bazie danych
generuje strukturę aplikacji webowej, z wszystkimi wymaganymi plikami
generuje podstronę logowania, przez co mechanizm autoryzacji jest już gotowy do rozszerzenia
generuje szkielet do testów oraz podstawowy test

Jak to działa?

Odpalmy zatem Flamingo – robimy to poprzez uruchomienie konsoli i wpisaniu ‘flamingo create project’ (binaria flamingo muszą być dostępne). Famingo zacznie ściągać wszystkie biblioteki, o ile ich już nie posiadamy w naszym lokalnym repozytorium Mavenowym i następnie uruchamia konsolowego wizarda. Nie będę opisywał kolejnych pytań, bo są raczej oczywiste – zamieszczę tylko zrzut z mojej konsoli:

Please choose the type of application to generate (flamingo-seam, flamingo-spring):[flamingo-spring]
flamingo-spring
Please enter the location in which your new application will be created (i.e. c:/java/development):
S:/_Projects/Java/J2EE
Enter the project name (e.g. myproject):
Flex
Please enter the root package name for your project (e.g. com.mydomain.myproject): [pl.j2ee.flamingo]
pl.j2ee.flex
Will this project have Flex or JavaFX user interface? (flex, javafx): [flex]
flex
Will this project use Hessian or AMF protocol? (amf, hessian): [amf]
amf
What kind of database are you using? (hsql, mysql, oracle, postgres, mssql, db2, sybase, none): [hsql]
hsql
Enter the JDBC URL for your database (e.g. jdbc:hsqldb:.): [jdbc:hsqldb:flex]
jdbc:hsqldb:flex
Enter database username: [sa]
sa
Enter database password: []

Do you want to update the database schema each time you deploy? (y, n): [y]
y
Enter the entity class name (Flex source files to view and modify entities will be generated as well):
Department
-------------------------------------------------------------------------------------
    G e n e r a t i n g   A n d r o M D A   P o w e r e d   A p p l i c a t i o n
-------------------------------------------------------------------------------------
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flamingoproject.properties'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flex/pom.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flex/src/main/flex/pl/j2ee/flex/view/DepartmentManager.mxml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flex/src/main/flex/pl/j2ee/flex/vo/Department.as'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flex/src/main/flex/main.mxml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/flex/src/main/resources/services-config.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/pom.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/readme.txt'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/pom.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/Department.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/DepartmentDAO.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/DepartmentDAOImpl.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/service/DepartmentService.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/service/ILoginService.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/java/pl/j2ee/flex/service/LoginService.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/resources/applicationContext-test.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/resources/applicationContext.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/resources/hibernate.cfg.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/webapp/index.html'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/main/webapp/WEB-INF/web.xml'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/test/java/pl/j2ee/flex/dao/DepartmentDAOTest.java'
    Output: 'file:/S:/_Projects/Java/J2EE/Flex/web/src/test/java/pl/j2ee/flex/DataSourceTestCase.java'
-------------------------------------------------------------------------------------
    New application generated to --> 'file:/S:/_Projects/Java/J2EE/Flex/'
-------------------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 24 seconds
[INFO] Finished at: Fri Nov 28 14:36:08 CET 2008
[INFO] Final Memory: 10M/20M
[INFO] --------------------------------------------------------------

No, i tyle :-) Proste, prawda?

Wygenerowany kod

Przechodzimy teraz do folderu gdzie wygenerował się nasz szkielet. Po wejściu do niego możemy zbudować cały projekt – poprzez ‘mvn clean install’. Po chwili – naszym oczom ukazuje się jakże pożądany komunikat: „Build Successful” (na konsoli widać także przeprowadzony test zapisu naszej klasy modelowej – także mechanizm testowania działa poprawnie). Świetnie, mamy coś co działa i się buduje, ale co tak naprawdę wygenerowaliśmy? Spróbujmy zatem zdeplyować naszą aplikację. Po wrzuceniu wara do Tomcata niestety okazuje się, że nie ma róży bez ognia – konsola krzyczy że nie mamy wymaganej biblioteki do HSQL. Przechodzimy zatem do odpowiedniego pliku POM (w web) i po jego otworzeniu – widzimy co jest nie tak. Usuwamy zbędną linijkę ‘test’ dla dependency HSQLDB, zapisujemy zmiany i ponownie budujemy projekt (‘mvn clean install’). Ponownie wrzucamy wara do tomcata i już – aplikacja wstała poprawnie!

Nie pozostaje nic innego jak teraz przejść do przeglądarki i zobaczyć nasze dzieło. Po uruchomieniu odpowiedniego adresu naszym oczom ukazuje się piękna strona we flashu, która żąda od nas danych do zalogowania. Dane te nie są istotne, to i tak jest stub – metoda do autoryzacji zawsze zwraca ‘true’ ;-) Po poprawnym zalogowaniu przechodzimy do jedynej dostępnej strony – listy obiektów domenowych (w moim przypadku ‘Department’). Mamy tutaj możliwość przeglądania wszystkich wpisów oraz funkcjonalności dodania nowego, edycji oraz usunięcia istniejącego. Sama lista oferuje jeszcze możliwość sortowania wyników. Ostatnią funkcjonalnością jest jeszcze oferowana przez guzik ‘Logout’ opcja wylogowania się z systemu. I to by było na tyle!

To działa!

Jak widać z powyższego tekstu – wystarczy ściągnąć Flamingo, rozpakować, odpalić wizarda i mamy już gotowy szkielet aplikacji RIA. Należy przy tym podkreślić, że w całym procesie od momentu pomysłu o szkielecie aplikacji flexowej do jej uruchomienia ani razu nie potrzebowalismy uruchomić żadnego IDE. Niesamowite! Co więcej, wygenerowany szkielet ten jest kompletny i tak naprawdę jest już w pełni działającą aplikacją o minimalnej funkcjonalności, przedstawiającą funkcjonalności bardziej na zasadzie ‘how to’. Wystarczy zaimplementować poprawne logowanie oraz rozszerzyć model dziedziny – i mamy w bardzo przystępny sposób pokazaną drogę w świat RIA.

Google Maps API i Java

Rafał Jaskółka — Fri, 03 Oct 2008 09:20:51 +0000

Prawdopodobnie tego bloga nie czyta nikt, kto nigdy nie używał Google Maps (beta ;-) ). Google od dłuższego czasu udostępnia API do Google Maps. Jako, że aplikacja jest napisana w języku javascript, tak też jest w wypadku API. Sama aplikacja jest w trakcie permanentnego rozwoju, wraz z nim zmienia się też interfejs programistyczny.

Konfiguracja i narzędzia
Jak sama nazwa wskazuje ten blog skupia się na szeroko pojętej korporacyjnej Javie, więc pokażę kilka zastosowań API w aplikacjach w tym języku. Oczywiście można sobie wyobrazić aplikację, która będzie wywoływać metody z Google Maps API bezpośrednio, ale żeby zaoszczędzić sobie pracy można wykorzystać np. otwarte rozszerzenie Apache Wicket wicket-contrib-gmap2.

Biblioteka ta jest dostępna w ramach Wicket Stuff – zbioru bibliotek nie należących do głównego projektu Apache Wicket, lecz silnie z tym frameworkiem powiązanych. W związku z czysto społecznościowym modelem rozwoju, i zmiennością samego Google Maps API, rozszerzenie w tej chwili nie ma w tej chwili stabilnego wydania. Jedną z ujemnych stron takiego modelu rozwoju jest konieczność samodzielnego zbudowania projektu ze źródeł, lub skorzystania z migawek aktualnego repozytorium.

Posłużę się podobnym schematem projektu jak w poprzednim wpisie na temat Wicketa choć tym razem z wykorzystaniem migawki rozwojowej gałęzi 1.4. W porównaniu do wersji 1.3.x zmiany związane są z pełniejszym wsparciem dla cech języka wprowadzonych w wersji 5 Javy. Pliki jar wicketa jak i projektu wicket-contrib-gmap2 są zawarte w repozytorium migawek Wicket Stuff, więc odpada konieczność samodzielnego budowania tych zależności.

Kod żródłowy
Całość projektu do zbudowania z użyciem mavena jest dostępna w tej paczce.

Klucz
Google Maps API wymaga wygenerowania klucza dla URL pod którym aplikacja będzie widoczna. Klucz można wygenerować na tej stronie, wymagane jest konto Google i zaakceptowanie warunków użycia API. Klucz będzie działał dla każdego URL (katalogu, domeny) rozpoczynającego się od ciągu użytego do jego wygenerowania. Dodatkowe informacje są zawarte na stronie na której klucz jest generowany. Pewnym ograniczeniem jest konieczność publicznego udostępnienia aplikacji korzystającej z API, chyba że zdecydujemy się na płatną wersję serwisu – Google Maps API Premier.

Klucz API (definiowany w GmapApplication.java) w przykładowym projekcie wygenerowany został dla http://localhost więc nie będzie konieczna jego zmiana dla aplikacji działającej lokalnie. API używane lokalnie traktuje klucz bardziej liberalnie, np. obsługuje aplikację uruchomioną na innym niż zadeklarowany porcie.

Przyjrzyjmy się klasie GmapApplication.java wywoływanej przy starcie aplikacji. W polu googleMapsApiKey zawarty jest klucz używany w całej aplikacji.

LiniagetMarkupSettings().setStripWicketTags(true); służy do wycięcia z wygenerowanego na podstawie szablonów HTML tagów specyficznych dla wicketa. Dodanie jej jest konieczne, by aplikacja w trybie DEVELOPMENT działała w Firefox 3. W klasie tej jest też konfigurowana domyślna strona – MapPage.

Współrzędne
Google Maps jako że jest szczególną formą mapy, ma też pewne wady map w ogólności. Podstawową jest próba odwzorowania powierzchni geoidy, którą w przybliżeniu jest ziemia w postaci płaskiej powierzchni. Twórcy map rozwiązują ten problem stosując różnego typu odwzorowania – w przypadku Google Maps jest to uproszczone odwzorowanie Mercatora. Odwzorowanie to bazuje na przekształceniu powierzchni geoidy na walec styczny do równika, i rozwinięciu powierzchni walca. Google maps dodatkowo traktuje powierzchnię ziemi jako idealną sferę, co upraszcza obliczenia na tyle by mogły one być prowadzone w API w języku javascript. Takie podejście obniża dokładność, ale głównym zadaniem Google Maps jest prezentacja ładnych, a nie wiernych map :-).

Kodowanie geograficzne – geocoding
Współrzędne na mapie są określone przez długość i szerokość geograficzną.Na podstawie takich współrzędnych działa też mechanika Google Maps. Ale w życiu codziennym takimi współrzędnymi posługujemy się bardzo rzadko, za współrzędne służy nam adres. Możliwość dość dokładnego odnajdywania miejsc z pomocą adresu w formie w jakiej używamy go na co dzień jest jedną z przyczyn sukcesu Google Maps i podobnych usług. Google udostępnił programistom taką funkcjonalność, zarówno jako konfigurowalny serwis HTTP, jak i interfejs w ramach samego API.

Pierwsza opcja jest o tyle ciekawa że można jej użyć na serwerze ( z ograniczeniami wynikającymi z licencji – ta funkcjonalność także wymaga klucza) do reprezentacji danych powiązanych geograficznie gdy cała informacja na temat lokalizacji ogranicza się do danych adresowych. Niestety dane geograficzne na temat terytorium Polski są dość gruboziarniste, czasami działają z dokładnością do ulicy, dla mniejszych miejscowości są jeszcze mniej dokładne.

W opisywanym projekcie wykorzystałem geocoding po stronie serwera – Kod jest zawarty w klasie GeoLocationClient, wykorzystuje klasę z gmap2-wicket-contrib ( Geocoder ). Ta klasa pobiera informacje w najprostrzej fomie – długości i szerokości geograficznej dla danego adresu, choć serwis ma większe możliwości, pozwala na wyciągnięcie dodatkowych informacji na temat lokalizacji w postaci pliku w formacie KML opartym na XML. Ten format ma szersze zastosowanie, w samym Google MAPs, ale też np. w aplikacji Google Earth.

Działanie przykładowego projektu
Strona po załadowaniu prezentuje mapę z polem tekstowym do wpisywania adresu. Na samej mapie wyświetlają się pinezki generowane dynamicznie. Pinezki są ładowane w momencie przesunięcia mapy i zmiany skali. Po kliknięciu w pinezkę, można zobaczyć współrzędne dla których została przyczepiona.

Jedyną stroną prezentowanego projektu jest MapPage, zawiera mapę z wyszukiwarką bazującą na wspomnianym wyżej serwisie:






Wicket Examples - GMap Panel










    
        
        topPanel

Jak widać szablon strony jest bardzo prosty, bardziej interesujące rzeczy dzieją się w kodzie źródłowym i javascripcie.

package pl.j2ee.wicket.gmap2.mappage;

import org.apache.wicket.PageParameters;
....
public class MapPage extends WebPage {

    private static final String ADDRESS = "Polska, Krak\u00F3w, Bociana 22";
    private static final int MARKERS_ON_X = 4;
    private static final int MARKERS_ON_Y = 4;

    private GMap2 map;

    public MapPage(final PageParameters parameters) {
        add(new StyleSheetReference("infoWindowCss", InfoWindowPanel.class, "infoWindow.css"));
        map = new GMap2("topPanel", GmapApplication.get().getGoogleMapsApiKey());
        add(map);
        setMapBaseSettings(map);
        map.add(new ClickListener() {

            private static final long serialVersionUID = 1L;

            @Override
            protected void onClick(AjaxRequestTarget target, GLatLng latLng, GOverlay overlay) {
                if (latLng != null) {
                    addMarker(map, latLng);
                }
            }
        });
        map.add(new DragEndListener() {

            private static final long serialVersionUID = 1L;

            @Override
            protected void onDragEnd(AjaxRequestTarget target) {
                regenerateMarkers();
            }
        });

        map.add(new ZoomEndListener() {

            private static final long serialVersionUID = 1L;

            @Override
            protected void onZoomEnd(AjaxRequestTarget target, int oldLevel, int newLevel) {
                regenerateMarkers();
            }
        });

        map.add(new LoadListener() {

            private static final long serialVersionUID = 1L;

            @Override
            protected void onLoad(AjaxRequestTarget target) {
                regenerateMarkers();
            }
        });
        add(new LocationPanel("locationPanel", new CompoundPropertyModel
(new AddressBean()), map));
    }

    private void setMapBaseSettings(final GMap2 map) {
        map.setDoubleClickZoomEnabled(true);
        map.setMapType(GMapType.G_HYBRID_MAP);
        map.setScrollWheelZoomEnabled(true);
        map.setDraggingEnabled(true);
        map.setMapType(GMapType.G_NORMAL_MAP);
        map.addControl(GControl.GLargeMapControl);
        map.addControl(GControl.GMapTypeControl);
        map.addControl(GControl.GScaleControl);
        String address = getStartAddress();
        GLatLng latLng = getAddressLocation(address);
        if (latLng != null) {
            map.setCenter(latLng);
        }
    }

    private GLatLng getAddressLocation(String address) {
        GeoLocatorClient geoLocatorClient = GmapApplication.get().getGeoLocatorClient();
        GLatLng latLng = geoLocatorClient.getAddressLocation(address);
        return latLng;
    }

    private String getStartAddress() {
        String address = new ResourceModel("address", ADDRESS).getObject();
        return address;
    }

    public GMarker getNewMarker(GLatLng location) {
        GMarkerOptions options = new GMarkerOptions(getPositionDescription(location));
        options.autoPan(true);
        options.bouncy(true);
        options.clickable(true);
        final GMarker result = new GMarker(location, options);

        return result;
    }

    private String getPositionDescription(GLatLng location) {
        return " latitude: " + location.getLat() + " longitude" + location.getLng();
    }

    public void regenerateMarkers() {
        map.removeAllOverlays();

        GLatLngBounds bounds = map.getBounds();
        GLatLng sw = bounds.getSW();
        GLatLng ne = bounds.getNE();
        double latSize = ne.getLat() - sw.getLat();
        double lngSize = ne.getLng() - sw.getLng();
        double latDelta = latSize / (MARKERS_ON_Y - 1);
        double lngDelta = lngSize / (MARKERS_ON_X - 1);
        for (double x = sw.getLng(); x < = ne.getLng(); x += lngDelta) {
            for (double y = sw.getLat(); y <= ne.getLat(); y += latDelta) {
                GLatLng latLng = new GLatLng(y, x);
                addMarker(map, latLng);
            }

        }
    }

    private GMarker addMarker(final GMap2 map, final GLatLng latLng) {
        final GMarker result = getNewMarker(latLng);
        map.addOverlay(result);
        result.addListener(GEvent.click, new GEventHandler() {

            private static final long serialVersionUID = 1L;

            @Override
            public void onEvent(AjaxRequestTarget target) {
                GInfoWindow infoWindow = map.getInfoWindow();
                infoWindow.open(result, new InfoWindowPanel("markerPanel", new CompoundPropertyModel(latLng)));
            }
        });
        return result;
    }
}

setMapBaseSettings służy do inicjalizacji mapy, dodaje podstawowe kontrolki. W tej metodzie również ustawiana jest też lokalizacja w której mapa startuje, na podstawie adresu.

        GLatLng latLng = getAddressLocation(address);
        if (latLng != null) {
            map.setCenter(latLng);
        }

Metoda regenerateMarkers() tworzy zestaw pinezek i dodaje je do mapy. Pinezki wcześniej dodane na mapie są usuwane. Można sobie wyobrazić, że pinezki pobierane z bazy danych na podstawie aktualnej skali i fragmentu mapy który jest właśnie wyświetlany. Ta metoda jest wywoływana z metod wywoływanych w wyniku zapytań AJAX z przeglądarki DragEndListener,ZoomEndListener,LoadListener.
Te metody są wywoływane odpowiednio po przesunięciu, zmianie skali i załadowaniu mapy.

Do pinezek podpięte jest zdarzenie AJAXowe odpalone po kliknięciu:

result.addListener(GEvent.click, new GEventHandler() {
            private static final long serialVersionUID = 1L;
            @Override
            public void onEvent(AjaxRequestTarget target) {
                GInfoWindow infoWindow = map.getInfoWindow();
                infoWindow.open(result, new InfoWindowPanel("markerPanel", new CompoundPropertyModel(latLng)));
            }
        });

Okno informacyjne jest generowane przez komponent InfoWindowPanel, jest to najzwyklejszy w świecie komponent Wicketa :-).

Wnioski
Projekt gmap2-wicket-contrib może być z powodzeniem punktem startowym dla rozwoju aplikacji korzystających z Google Maps i dodatkowych źródeł danych, zbyt dużych żeby przechowywać je po stronie klienta. Jednak ten projekt korzysta tylko z małej części możliwości Google Maps API. Skorzystanie z pozostałych wymaga dopisania nowych komponentów bezpośrednio wywołujących metody z API, te istniejące mogą być traktowane jako wzorzec i źródło pomysłów.

JavaRebel

Michał Gołacki — Tue, 16 Sep 2008 11:49:20 +0000

Zdarzyło wam się kiedyś pracować z aplikacją, której deploy trwał tak długo, że można było zapomnieć co tak właściwie chcieliście uruchomić? Być może uda nam się znaleźć rozwiązanie tego problemu. JavaRebel jest pluginem do maszyny wirtualnej. Pozwala na przeładowywanie klas bez konieczności restartowania serwera.

Konfiguracja

Konfiguracja nie jest szczególnie skomplikowana, do uruchomienia potrzebny będzie sam JavaRebel oraz serwer aplikacji. Osobiście przetestowałem serwery aplikacjyjne JBoss 4.2.3.GA oraz Tomcat 5.5.26 deployując na nich aplikację Spring’ową.

W obu przypadkach dodajemy linię:
set JAVA_OPTS=-noverify -javaagent:javarebel.jar -Drebel.dirs= -%JAVA_OPTS%
uzupełniając “-Drebel.dirs=” o katalogi do których nasze IDE kompiluje klasy, oddzielając je przecinkami. W przypadku JBoss’a plikiem do którego dodajemy linię jest run.bat, natomiast dla Tomcat’s będzie to catalina.cmd.

Plik javarebel.jar umieszczamy w tym samym miejscu, w którym znajdował się edytowany przez nas wcześniej, czyli katalogu bin serwera.

Działanie

Teraz możemy już uruchomić serwer. Naszą aplikację deployujemy na serwerze normalnie, wrzucając w odpowiednie miejsce plik war. Aplikacja zostanie uruchomiona, a JavaRebel rozpocznie monitorowanie folderu podanego wcześniej, sprawdzając czy któraś z naszych klas nie została zmieniona. Monitorowanie zmian odbywa się na podstawie znaczników czasu w klasach. Przeładowanie klasy zachowuje wszystkie istniejące instancje.

JavaRebel pozwala nam na wykonanie szeregu operacji na naszych klasach. Możemy zarówno dodawać jak i usuwać metody, konstruktory, pola, klasy czy adnotacje. Oczywiście pozwala nam zmieniać ciała samych metod. Niestety, ograniczeniem jest brak możliwości zamiany klasy bazowej oraz dodawanie/usuwanie interfejsów. Wydaje mi się jednak, że nie są to tak częste operacje, aby mogły stanowić problem.

Spring

W ostatnim czasie pojawił się plugin do JavaRebel wspierający jego działanie ze Springiem. Wspiera on rejestrowanie nowych bean’ów, kontrolerów, zarządzanie zależnościami. Wszystkie powyższe operacje mogą być wykonywane zarówno przy użyciu konfiguracji w XML’u jak i adnotacji. Co prawda narzędzie jest udostępnione jako open source, jednak wciąż należy je traktować jako wersję beta.

Licencja

Jest chyba największą wadą tego narzędzia, nie jest ono tanie. Licencja ciągła przy zakupie poniżej dziesięciu kosztuje 249$, a licencja roczna to koszt 99$. Cena licencji spada wraz z ich ilością.

Autorzy podają, że narzędzie to jest aktualnie używane przez wszystkich developerów serwisu LinkedIn. Ponadto posiadacze brązowego pasa na www.javablackbelt.com mogą otrzymać licencję za darmo.

Wrażenia

Osobiście ten sposób wprowadzania zmian w aplikacji bardzo przypadł mi do gustu. Nie zauważyłem opóźnień związanych z przeładowywaniem klas. Zależności były zawsze na miejscu dzięki możliwości zachowania istniejących instancji bean’ów. Uważam, że jest to narzędzie warte rozważenia, szczególnie w przypadku aplikacji, których deployment zajmuje pokaźną ilość czasu. Jednak z tego co zdążyłem wyczytać na forum projektu, pojawiają się problemy z obsługą EJB i generalnie nie istnieje wsparcie dla jakichkolwiek frameworków (poza Springiem). Jednak istnieje możliwość darmowego przetestowania, czy narzędzie spełnia nasze oczekiwania.

Moim zdaniem jest to bardzo przydatne oprogramowanie przy przygotowaniu aplikacji springowych, jednak jego cena jest nieco wygórowana, biorąc pod uwagę kłopoty z EJB i brak wsparcia dla innych frameworków.

Apache Wicket – trochę inny framework

Rafał Jaskółka — Mon, 07 Jul 2008 12:55:21 +0000

Apache Wicket to komponentowy framework (szkielet) dla aplikacji WWW. Możecie sobie zadać pytanie po co jeszcze jedno narzędzie, skoro mamy Struts, JSF, Spring MVC itd…

Nudne wprowadzenie

Wicket jest alternatywą dla wyżej wymienionych, stara się zmniejszyć do minimum ilość metadanych zapisanych w dziesiątkach kilobajtów złożonych plików XML i przywrócić programiście możliwość pisania w Javie.

Wicket pozwala na oddzielenie kodu HTML od logiki aplikacji, nie dostarcza wielu gotowych komponentów, lecz umożliwia łatwe tworzenie własnych i rozszerzanie istniejących.
Framework bazuje bezpośrednio na specyfikacji serwletów, w oparciu o nią pozwala na budowę aplikacji z komponentową warstwą widoku. Inne rozwiązania tego typu, napisane w Javie, zazwyczaj wymuszają użycie stron JSP. Takie rozwiązanie, w wielu przypadkach wygodne, słabo nadaje się do realizowania podejścia obiektowego, czasami wymusza łamanie jego zasad. Dynamiczne generowanie HTML-a realizowane jest tam poprzez mieszanie tagów JSTL, wyrażeń EL, kodu HTML, fragmentów w Javie. W rezultacie powstaje trudny do odczytania i pielęgnacji kod podobno przypominający spaghetti :-). Moim skromnym zdaniem to porównanie jest obrazą dla tak zacnego posiłku.

W zależności od preferencji rezygnacja z metadanych zapisanych w plikach XML może być wadą lub zaletą. Mocnymi stronami takiego rozwiązania są lepsza podatność kodu na zmiany i możliwość korzystania ze standardowych narzędzi do refaktorowania kodu.

Pojedynczy komponent w Wicket składa się z dwóch części: kodu w Javie oraz pliku HTML. Komponenty mogą być dziedziczone. Dotyczy to zarówno części w HTML jak i w Javie.

Plik HTML korzysta ze standardowych znaczników, elementy obce są ograniczone do atrybutów wicket:id identyfikujących poszczególne komponenty oraz kilku znaczników specyficznych dla Wicket. Znaczniki te odpowiadają za wprowadzanie punktów w których kontrolę przejmuje kod w Javie.

Zachowania dynamiczne (pętle, bloki wyświetlane po spełnieniu pewnych warunków) są obsługiwane w pełni w części Javowej komponentów. Taka organizacja umożliwia podział odpowiedzialności pomiędzy programistę i projektanta WWW, pliki HTML komponentów można zmieniać za pomocą standardowych narzędzi do tego przeznaczonych.

Do roboty!

Kody źródłowe to tego przykładu są tu.

Autorzy Wicket rekomendują projekt Apache Maven 2 jako narzędzie do budowania projektów opartych o ten szkielet. Rzeczywiście stworzenie szkieletu aplikacji z wykorzystaniem tego narzędzia jest łatwe i przyjemne :). Opis instalacji Mavena można znaleźć na stronie projektu.

Po zainstalowaniu narzędzia wydajemy polecenie:

mvn archetype:create
-DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=1.3.4
-DgroupId=pl.j2ee.wicket
-DartifactId=j2ee_wicket

j2ee_wicket będzie nazwą naszego projektu.
pl.j2ee.wicket to nazwa pakietu, w którym znajdziemy wygenerowany kod.

Projekt można łatwo importować do ulubionego IDE. W przypadku eclipse warto użyć wtyczki m2eclipse, w nowszych wersjach dobrze integrującej się z WTP – zestawem wtyczek dla programistów aplikacji webowych.

Po wykonaniu tych kroków mamy gotowy do uruchomienia prosty projekt. Pozostaje nam tylko uruchomienie klasy j2ee.pl.Start jako zwykłej aplikacji Javowej i nakierowanie przeglądarki na http://localhost:8080/j2ee_wicket. Projekt można uruchomić również z poziomu mavena – z celem jetty:run:

mvn install
mvn jetty:run

Jeżeli udało się wszystko dobrze skonfigurować, oczom naszym powinien ukazać się tryumfalny komunikat:
Wicket Quickstart Archetype Homepage
If you see this message wicket is properly configured and running

Jako że j2ee.pl.Start jest zwykłą klasą Javową debugowanie naszego projektu będzie równie łatwe jak to jest w przypadku zwykłej aplikacji dla platformy JSE.

Na początek możemy sprawić by aplikacja robiła coś więcej. Zacznijmy od dodania klasy która będzie implementować prostą logikę:

package pl.j2ee.wicket.model;

import java.io.Serializable;

public class Suma implements Serializable {

    private static final long serialVersionUID = 6261687669280596713L;
    private Integer skladnik1;
    private Integer skladnik2;

    public Integer getSkladnik1() {
        return skladnik1;
    }

    public void setSkladnik1(Integer skladnik1) {
        this.skladnik1 = skladnik1;
    }

    public Integer getSkladnik2() {
        return skladnik2;
    }

    public void setSkladnik2(Integer skladnik2) {
        this.skladnik2 = skladnik2;
    }

    public Integer getSuma() {
        if (skladnik1 != null && skladnik2 != null) {
            return new Integer(skladnik1.intValue() + skladnik2.intValue());
        }
        return null;
    }

}

Dodajemy szablon SumaPage.html w pakiecie pl.j2ee.wicket


    
        J2ee wicket
    
    
        miejsce na statyczny komunikat        
            
            
            
        
         wynik obliczen

Wartości w atrybutach wicket:id będą identyfikatorami komponentów zdefiniowanych w SumaPage.java

package pl.j2ee.wicket;

import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Button;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.BoundCompoundPropertyModel;
import org.apache.wicket.model.Model;
import org.apache.wicket.model.PropertyModel;

import pl.j2ee.wicket.model.Suma;

/**
 * Suma
 */
public class SumaPage extends WebPage {

    private static final long serialVersionUID = 1L;
    protected Label resultLabel;
    protected Suma suma;

    public SumaPage(final PageParameters parameters) {
        add(new Label("komunikat", "Podaj dwie liczby całkowite"));
        suma = new Suma();
        Form dodajForm = new Form("dodaj", new BoundCompoundPropertyModel(suma));
        TextField skladnik1 = new TextField("skladnik1");
        dodajForm.add(skladnik1);
        TextField skladnik2 = new TextField("skladnik2");
        dodajForm.add(skladnik2);
        resultLabel = getResultLabel();
        add(resultLabel);
        dodajForm.add(getSubmitButton(dodajForm));
        add(dodajForm);
    }

    protected Label getResultLabel() {
        return new Label("suma", new PropertyModel(suma, "suma"));
    }

    protected Button getSubmitButton(Form form) {
        return new Button("sumuj", new Model("Sumuj"));
    }
}

Klasa SumaPage definiuje główny komponent dla strony o tej samej nazwie. Strona jest budowana poprzez organizowanie komponentów w drzewo. Węzły w tym drzewie stanowią obiekty implementujące interfejs Component. Tylko obiekty klas implementujących interfejs MarkupContainer (kontenery) mogą zawierać inne komponenty.

Jednym z tego typu komponentów jest formularz:

Form dodajForm = new Form("dodaj",new BoundCompoundPropertyModel(suma));

W tej linii definiujemy formularz o identyfikatorze dodaj (taki sam jak w pliku HomePage.html), oraz model powiązany z tym komponentem (BoundControlPropertyModel). Wicket zawiera wiele typów modeli, ten ma największe możliwości, pozwala komponentom składowym na dostęp do pól składowych obiektu modelu kontenera.

Według przyjętej konwencji jeżeli dla komponentu składowego formularza nie podano modelu, wicket próbuje powiązać ten komponent z modelem formularza interpretując identyfikator komponentu jako nazwę pola w obiekcie modelu formularza.

Nazwy skladnik1 i skladnik2 muszą być takie same jak nazwy pól w obiekcie suma.

TextField skladnik1 = new TextField("skladnik1");
dodajForm.add(skladnik1);
TextField skladnik2 = new TextField("skladnik2");
dodajForm.add(skladnik2);

Musimy dodać przycisk wysyłający formularz i podpiąć formularz do strony. Klasa Model definiuje niemodyfikowalny model, w tym przypadku zawsze będzie to podany String.

    dodajForm.add(getSubmitButton(dodajForm));
    add(dodajForm);
    .
    .
    .
    protected Button getSubmitButton(Form form) {
        return new Button("sumuj", new Model("Sumuj"));
    }

Rezerwujemy miejsce w którym zobaczymy wynik obliczeń. PropertyModel działa podobnie do BoundControlPropertyModel lecz wiąże tylko jedno pole w beanie. Z modelu tej klasy możemy skorzystać też w elemencie formularza.

    resultLabel = getResultLabel();
    add(resultLabel);
    .
    .
    .
    protected Label getResultLabel() {
        return new Label("suma", new PropertyModel(suma, "suma"));
    }

By dostać się na nowo dodaną stronę, musimy dodać odnośnik na stronie głównej, odpowiednie zmiany w HomePage.java i HomePage.html:

add(new PageLink("sumaLink", SumaPage.class));


Suma

Pozostaje uruchomienie przykładu i radość z osiągniętych wyników :-).

Wicket i AJAX

Wicket zawiera ciekawą obsługę technologii AJAX. Aby ją wykorzystać w naszym przykładzie wystarczy mała modyfikacja klasy SumaPage. Ale możemy też wykorzystać mechanizm dziedziczenia:

Dodajemy klasę SumaAjaxPage:

package pl.j2ee.wicket;

import org.apache.wicket.PageParameters;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.form.AjaxButton;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Button;
import org.apache.wicket.markup.html.form.Form;

/**
 * Suma i ajax
 */
public class SumaAjaxPage extends SumaPage {

    protected Label getResultLabel() {

        Label resultLabel2 = super.getResultLabel();
        resultLabel2.setOutputMarkupId(true);
        return resultLabel2;
    }

    protected Button getSubmitButton(Form form) {
        return new AjaxButton("sumuj", form) {

            private static final long serialVersionUID = -7912898126800181416L;

            protected void onSubmit(AjaxRequestTarget target, Form dodajForm) {
                target.addComponent(resultLabel);
            }
        };
    }

    public SumaAjaxPage(PageParameters parameters) {
        super(parameters);
    }
}

Metoda onSubmit w obiekcie klasy anonimowej dziedziczącej z AjaxButton jest wywoływana po naciśnięciu przycisku Sumuj w wyniku asynchronicznego zapytania z przeglądarki. W tej metodzie możemy zadeklarować które z komponentów powinny być odświeżone. Wicket wysyła w odpowiedzi fragmenty kodu HTML odpowiadające wybranym komponentom. Po stronie przeglądarki w odpowiedni sposób zmieniane jest drzewo DOM strony. Aby taka podmiana była możliwa, komponenty powinny posiadać atrybut id, który domyślnie nie jest obecny. Aby to zmienić należy wykonać na odświeżanych komponentach w momencie ich tworzenia metodę setOutputMarkupId(true). W naszym przykładzie oznacza to dodanie linii:

 resultLabel2.setOutputMarkupId(true);

Na stronie głównej dodajemy link do SumaAjaxPage:

add(new PageLink("sumaAjaxLink", SumaAjaxPage.class));


Suma Ajax

Po wejściu przez odnośnik Suma Ajax przyciśnięcie sumuj nie powoduje przeładowania strony, lecz tylko odświeżenie fragmentu z rezultatem. Dlaczego ten przykład działa skoro nie dodaliśmy pliku SumaAjaxPage.html? To kolejna przyjemna cecha Wicketa – dziedziczona może być nie tylko implementacja w Javie, ale też szablony HTML, po prostu strona SumaAjaxPage używa szablonu SumaPage.html !

Testowanie

Na stronie pojawił się element którego nie dodawaliśmy (odnośnik opisany WICKET AJAX DEBUG). Wynika to z tego że aplikacja jest uruchomiona jest w trybie debug. Po kliknięciu w ten odnośnik wyświetla się okno, w którym możemy zobaczyć wywołania AJAX z przeglądarki i odpowiedzi na te zapytania, coś co bardzo przydaje się przy debugowaniu bardziej złożonych aplikacji.

Wicket zawiera klasę WicketTester służącą do testów jednostkowych komponentów. Została napisana z użyciem asercji JUnit, ale działa również z TestNG. Za pomocą tego narzędzia w dużym stopniu można zamodelować sposób używania aplikacji przez użytkownika, można sprawdzić nie tylko pojedyncze komponenty ale też scenariusze obejmujące wiele stron WWW. Testowalne są również akcje AJAX!

Testy dla opisanych tu komponentów znajdują się w załączonym kodzie źródłowym.

Co dalej?

Wicket stosunkowo łatwo rozszerzać. Dowodem na to może być choćby zestaw zewnętrznych modułów zgrupowanych w projekcie Wicket stuff .

Dokumentacja do Wicket nie jest rewelacyjna i daleko jej do kompletności, ale otwarte kody źródłowe są na tyle dobrze napisane, że braki łatwo uzupełnić po prostu je przeglądając. W trudnych przypadkach warto zadać pytanie na liście dyskusyjnej wicket-user, odpowiedzi na dobrze zadane pytania przychodzą szybko :-)

JasperReport – część II

Dariusz Sot — Fri, 04 Jul 2008 07:56:50 +0000

Ze względu na fakt że zdecydowana większość aplikacji ma jako część funkcjonalności szeroko pojęte generowanie raportów – ponownie na warsztacie znalazł się Jasper. Tym razem jednak postaram się przedstawić sposób na proste tworzenie raportów wymagających nie tylko dynamicznej ilości wierszy, ale także i kolumn. Nie będę się skupiać na tematach omówionych w poprzednim artykule o Jasperze i omówię tylko to co jest tu ‘nowością’, łącznie z krótkim opisem użycia narzędzia iReport.

Problem

Stosunkowo łatwo można wyobrazić sobie raport, w którym musimy przedstawić dane w nieznanym z góry rozmiarze. O ile dodawanie nowych elementów w pionie jest trywialnym zagadnieniem w Jasperze, tak generowanie danych w poziomie jest już dość kłopotliwe. Raport z dynamiczną ilością zarówno kolumn jak i wierszy wydaje się być niemożliwym do zrobienia. Na szczęście iReport posiada dość nietypowy element który można umieścić na raporcie. Jest to tabela krzyżowa (crosstab). Jak można przypuszczać – służy ona do obsługi tych nietypowych sytuacji.

Tworzenie szablonu raportu

Zacznijmy zatem. Na początku potrzebne będzie nam DTO do przechowania danych które chcemy wyświetlić.

public class ReportElementDTO {

   private String columnName;
   private String rowName;
   private Integer value;

    public String getColumnName() {
        return this.columnName;
    }
    public void setColumnName(String columnName) {
        this.columnName = columnName;
    }
    public String getRowName() {
        return this.rowName;
    }
    public void setRowName(String rowName) {
        this.rowName = rowName;
    }
    public Integer getValue() {
        return this.value;
    }
    public void setValue(Integer value) {
        this.value = value;
    }
}

Następnie w iReporcie tworzymy sobie nowy raport i definiujemy w nim jako źródło danych przedstawioną powyżej strukturę (najprościej poprzez Data -> Report Query -> JavaBean Data Source):

Następnie tworzymy Tabelę krzyżową. Pojawia się wizard, w którym mamy możliwość zdefiniowania wszystkich parametrów tabeli. Na początku wybieramy raport z którego nasza tabela będzie korzystała (obiekty, parametry, itd – czyli nasz dokument):

Następnie wybieramy parametr który ma być brany jako kolejne wiersze:

Następnie wybieramy parametr który ma być brany jako kolejne kolumny:

Kolejnym krokiem jest określenie zachowania części z danymi. Tu oprócz pola z danymi podajemy także funkcję która będzie odpowiedzialna za przetworzenie danych w kolumnach/wierszach. Tu najczęściej wykorzystywaną opcją jest suma:

Następnie określamy czy nasza tabela ma mieć kolumnę/wiersz podsumowujący oraz czy chcemy mieć widoczną siatkę pomiędzy polami:

Pozostało tylko zatwierdzić podane powyżej informacje i mamy już gotową tabelę!

Jak to działa?

W wyniku powyższych czynności w iReporcie powstaje standardowy raport z tabelą krzyżową oraz dodatkowa karta właściwości tej tabeli. Tam można podejrzeć wszystkie podane wcześniej ustawienia i je zmodyfikować. Na tej części można także dodać dodatkowe informacje (na przykład zdefiniować kolumny podsumowań jako nazwy brane z Resource Bundle’a).

W jaki sposób zasilić taką tabelę danymi? Otóż jest to osiągane poprzez odpowiednią konstrukcję źródła danych. Jako dane przysyła się zwykłą jednowymiarową listę przedstawionych powyżej obiektów ReportElementDTO, sam Jasper zajmuje się odpowiednim przetworzeniem tej listy. W skrócie działa to tak że z jednowymiarowej listy jest tworzona dwuwymiarowa macierz, przy czym wartości są grupowane poprzez stwierdzenie ‘równości’ danych w odpowiednich property. W przypadku gdy zdefiniowaliśmy ‘columnName’ jako property odpowiadające za nazwę danej kolumny – dane się pojawią w kolejnych wierszach dla tych elementów z listy, które spełniają warunek ‘equals’ na danej wartości ‘columnName’. Analogiczna sytuacja jest w przypadku wierszy (tu odpowiada za to property ‘rowName’). Dodatkowo mozna zdefiniować swój własny sposób porównywania tych wartości, łącznie z kierunkiem sortowania. Logika nakazuje uważać że property ‘value’ odpowiada za wyświetlaną wartość. I tak właśnie jest, należy jednak pamiętać o wykorzystanej funkcji – w moim przypadku dzięki funkcji ‘sum’ pojawią się tu wartości będące sumą wszystkich wystąpień danego elementu. Jak np. na liście źródłowej znajdą się dwa identyczne z punktu widzenia tabeli krzyżowej dane (odpowiednio ‘columnName’ oraz ‘rowName’ są takie same) – wartości ‘value’ będą zsumowane. Poza tą funkcją są dostępne jeszcze inne ciekawe funkcje, choćby ‘count’, która po prostu liczy ilość wystąpień danego elementu.

Aplikacja

W celu zobrazowania możliwości tabel krzyżowych napisałem małą aplikację opartą o Springa. Jest to rozwinięcie poprzedniej aplikacji stworzonej na potrzeby wspomnianego już poprzedniego artykułu o Jasperze. Większość użytych rzeczy jest tam opisana. Aplikacja jest bardzo prosta, jej praca polega na przyjęciu od użytkownika wartości które zostaną następnie użyte do wygenerowania odpowiedniej wielkości tabeli krzyżowej. Całość kodu jaki powstał, łącznie z plikiem szablonu raportu w formacie ‘*.jrxml’ jest dostępny pod tym adresem.

Podsumowanie

Tabela krzyżowa jest stosunkowo prostą konstrukcją, która w miarę przystępny sposób umożliwia definiowanie dynamicznych raportów. Po odpowiednim zaprojektowaniu szablonu jedyną większą trudnością jest właściwe przygotowanie źródła danych. Jak widać jednak z załączonego kodu, całość jest zdecydowanie mniej straszna niż by się wydawało.

Osobną kwestią jest samo narzędzie iReport. Mimo swoich wad jest to bardzo przydatne narzędzie i po pewnej praktyce staje się niesamowicie przydatny. Można w nim bardzo szybko stworzyć szablon raportu który po przekompilowaniu do formatu ‘*.jasper’ staje się gotowym do użycia plikiem. Uważam że iReport jest bardzo dobrym narzędziem do przygotowywania szablonów raportów. Mimo swoich wad bardzo pomaga w procesie tworzenia tych szablonów, dzięki czemu możemy się skupić na tym co tak bardzo lubimy – kodowaniu ;-)

Grails – koniec poszukiwań?

Jacek Byczyński — Mon, 30 Jun 2008 08:53:18 +0000

Niespełna dwa lata temu zaczął powstawać nowy framework – Grails, służący do budowy aplikacji webowych oparty na skryptowym języku programowania – Groovy. Od niedawna Grails coraz częściej przyciąga uwagę, a głównym powodem jest fakt, że prostą aplikacje webową można wykonać kilkoma poleceniami z konsoli, no może jeszcze dwie, trzy linijki kodu. Myślę, że warto przyjrzeć się nowemu rozwiązaniu, które upraszcza oraz przyspiesza tak znacznie prace i pokazać jego możliwości.

Na początek powiem kilka słów o samym Groovy, który jest określany czasem nową, super wersją Javy. Jak można przypuszczać język ten przejął wiele od swojego „rodzica”, wśród podobieństw na pewno możemy wymienić taki sam model dziedziczenia, sposób tworzenia klas, pakietów, metod. Język ten jest dynamicznie typowany, działa na JVM, jest kompilowany do bytecodu i bardzo dobrze integruję się z Java. Stosowanie niezdefiniowanych typów, ułatwia tworzenie i parsowanie XML, które jest silnie wspierane w Groovym. Dodatkowo uproszczone jest testowanie przez wbudowanie Junit, obiektów mock. Zachęcam do szerszego zapoznania się z tym językiem, wszystkie potrzebne informacje można znaleźć na stronie –
http://groovy.codehaus.org.
Wracając do tematu pracę z Grails rozpoczynamy od ściągnięcia frameworka z http://www.grails.org/Installation.
Wykonujemy instalacje według instrukcji na stronie, następnie otwieramy konsole i jeśli wszystko działa po wpisaniu polecenia grails otrzymujemy przywitanie „Welcome to Grails 1.0.3 …” . W tym momencie mamy już wszystko co jest potrzebne do wykonania aplikacji webowej opartej na modelu MVC. Nie musimy dodatkowo ściągać serwera , czy bazy danych. Grails wykorzystuje praktycznie wszystko co jest napisane i sprawdzone w Javie (Spring, Hibernate, SiteMesh, Ant, Jetty, Hsqldb). Główną ideą frameworka jest “Convention-over-configuration” co według założeń powinno znacznie przyspieszyć nam prace.
W ramach zapoznania się z Grails chciałbym wykonać aplikację do zarządzania użytkownikami i ich prawami. Wykorzystam do tego plugin Acegi. Grails posiada wiele pluginow, które możemy używać w zależności od potrzeb.
Najpierw tworzymy skonfigurowaną aplikacje ,oraz gotowa strukturę katalogów poleceniem : grails create-app user-app. Po zaimportowaniu do eclipsa aplikacja wygląda następująco :

Domyślnie mamy podpiętą bazę hsqldb, skonfigurowanego siteMesha, oraz pierwsze strony widoku z rozszerzeniem gsp. Jeżeli ktoś zna technologie jsp to wystarczy zapoznać się z nowym tagiem rozpoczynającym się od prefixu , jest on odpowiednikiem popularnego w springu .
Aby skorzystać z pluginu Acegi należy go zainstalować poleceniem: grails install-plugin acegi, a następnie stworzyć klasy domenowe: grails create-auth-domains User Role.
Przyjrzyjmy się teraz wygenerowanej klasie User:

class User {
   static transients = ['pass']
   static hasMany = [authorities: Role]
   static belongsTo = Role

   /** Username */
   String username
   /** User Real Name*/
   String userRealName
   /** MD5 Password */
   String passwd
   /** enabled */
   boolean enabled

   String email
   boolean emailShow

   /** description */
   String description = ''

   /** plain password to create a MD5 password */
   String pass = '[secret]'

   static constraints = {
      username(blank: false, unique: true)
      userRealName(blank: false)
      passwd(blank: false)
      enabled()
   }
}

W klasie tej mamy zdefiniowana relacje dzięki linijce: static hasMany = [authorities: Role], oraz walidacje: static constraints = {..} Możemy tudaj dodawać własne reguły walidacji np: size:5..15, tak aby nazwa nie była za krótka ani za długa.
Nie mamy jeszcze kontrolerów, ani widoków do zarządzania logowaniem, w tym celu wykonujemy: grails generate-manager .Po wykonaniu tego polecenia mamy strony gsp oraz kontrolery CRUD(create ,read, update,delete) dla każdej klasy domenowej.
Tworzymy jeszcze stronę główną naszej aplikacji, zaczynamy od kontrolera: grails create-controller Welcome.
Wygenerowany kontroler modyfikujemy w następujący sposób:

class WelcomeController {
    def index = { render(view:"welcome")}
}

W katalogu user-app/grails-app/views/welcome tworzymy widok welcome.gsp:


    
        user-app
		
    
    
        Lista akcji:
        
            
              
                    ${c.fullName}

Teraz modyfikujemy index.gsp, żeby aplikacja startowała od strony powitalnej:

< % response.sendRedirect("welcome" ) %>

Możemy już uruchomic naszą aplikacje poleceniem: grails run-app i w przeglądarce podajemy adres : http://localhost:8080/user-app, otrzymujemy widok z dostępnymi kontrolerami:

Prace z aplikacją zaczynamy od skonfigurowania roli:

Następnie dodajemy nowego użytkownika:

Na końcu tworzymy maping dla strony powitalnej:

W tym momencie po otwarciu strony głównej pojawi się nam okienko logowania, aby uzyskać dostęp wprowadzamy login i hasło.
W zasadzie wszystko już mamy gotowe, nie wiele się napracowaliśmy, a część aplikacji jest gotowa, można jeszcze dodać message, aby wszystko było w języku polskim. Nie mamy też zaimplementowanej warstwy serwisowej, co wymaga dodatkowej pracy.
Obecnie istnieje już wiele projektów wykonanych z sukcesem na Grails, myślę, że będzie ich bardzo szybko przybywać. O powodzeniu nowego frameworka na pewno będzie stanowić używanie sprawdzonych technologi i moc pluginów, które znacznie przyspieszają pracę. Wydaje mi się, że na tą chwile trudno o lepsze rozwiązanie i każdy szybko doceni usprawnienia oferowane przez Grails.

JackRabbit

Piotr Święciak — Fri, 20 Jun 2008 12:57:46 +0000

Jackrabbit jest najpopularniejszą darmową implementacją JCR dla technologii Java. Ale zacznijmy od początku, co to jest JCR? Java Content Repository jest repozytorium treści o strukturze drzewiastej, które dzięki zdolności definiowania typów węzłów i liści, bardzo rozszerza możliwości tego narzędzia. Mamy kilka wbudowanych typów (np. katalog, plik, link ) ale możemy również sami definiować nowe typy. Kolejnymi możliwościami są: tekstowe przeszukiwanie czy zarządzanie wersjami. JCR jest wiec idealnym narzędziem do budowania systemów zarządzania treścią. W artykule jako przykład stworzymy aplikację, która będzie korzystać z możliwości wersjonowania.

Konfiguracja JCR

Zaczynamy od konfiguracji Jackrabbita na serwerze (w naszym przykładzie Tomcat6). Proces składa się z trzech etapów:

Kopiujemy do katalogu lib na serwerze potrzebne biblioteki (w pliku pom.xml są wszystkie dependency, także można pobrać źródła aplikacji i maven pobierze nam potrzebne biblioteki):
- jcr-1.0.jar
- jackrabbit-api-1.4.jar
- jackrabbit-core-1.4.jar
- jackrabbit-jcr-commons-1.4.jar
- jackrabbit-spi-1.4.jar
- jackrabbit-spi-commons-1.4.jar
- jackrabbit-text-extractors-1.4.jar
- slf4j-api-1.3.0.jar
- slf4j-simple-1.3.0.jar
- commons-collections-3.1.jar
- lucene-core-2.2.0.jar
- derby-10.2.1.6.jar
- concurrent-1.3.4.jar
Konfiguracja pliku conf/server.xml. W GlobalNamingResources definiujemy Resource.
Parametr configFilePath definiuje ścieżkę dostępu do pliku konfiguracyjnego repozytorium – repository.xml. W repHomeDir podajemy ścieżkę do katalogu domowego repozytorium. W naszym przypadku widzimy ze repozytoriom znajduje się w katalogu webapps naszego serwera.
Konfiguracja pliku conf/context.xml

Mamy już skonfigurowany serwer oraz podane ścieżki gdzie znajdować się będzie nasze repozytorium. Teraz musimy skonfigurować plik repository.xml, a następnie skopiować go w miejsce które podaliśmy w configFilePath.

Mamy już skonfigurowany JCR. Teraz zajmiemy się nasza przykładową aplikacją.

Aplikacja
Jako przykład stworzymy prostą aplikacje webową w oparciu o szkielet springa. Na stronie będzie przykładowy formularz, odzwierciedlający dokument, który będzie zapisywany a zarazem wersjonowany w naszym repozytorium. Oczywiście zaczynamy od stworzenia szkieletu projektu:

mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=pl.j2ee.jcr_example -DartifactId=jcr-example

Kolejnym krokiem jest konfiguracja pliku pom.xml


	4.0.0
	pl.j2ee
	jcr-example
	war
	1
	jcr-example
	http://maven.apache.org
	
		
			
				maven-compiler-plugin
				
					utf8
					1.6
					1.6
				
			
		
	
	
		
			org.springframework
			spring
			2.5.4
		
		
			org.springframework
			spring-webmvc
			2.5.4
		
		
			taglibs
			standard
			1.1.2
		
		
			javax.servlet
			jstl
			1.2
		
		
			javax.servlet
			servlet-api
			2.5
			provided
		
		
			org.apache.jackrabbit
			jackrabbit-api
			1.4
		
		
			org.apache.jackrabbit
			jackrabbit-core
			1.4.4
		
		
			javax.jcr
			jcr
			1.0
			provided
		
		
			org.slf4j
			slf4j-log4j12
			1.0
		
		
			log4j
			log4j
			1.2.8

Teraz tworzymy prosty model naszego przykładowego dokumentu.

package pl.j2ee.jcr_example;
import java.io.Serializable;
import java.util.Date;

public class DocumentJcr implements Serializable {

    private static final long serialVersionUID = 1L;
    private String name;
    private String title;
    private Date date;
    private String text;

    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String getTitle() {
        return title;
    }
    public void setTitle(String title) {
        this.title = title;
    }
    public Date getDate() {
        return date;
    }
    public void setDate(Date date) {
        this.date = date;
    }
    public String getText() {
        return text;
    }
    public void setText(String text) {
        this.text = text;
    }
}

Service do obsługi repozytorium

package pl.j2ee.jcr_example.service;

import ...

public class DocumentService implements IDocumentService {

    public final Session sessionLogin() {

        InitialContext ctx;
        try {
            ctx = new InitialContext();

            Context environment = (Context) ctx.lookup("java:comp/env");
            Repository repository = (Repository) environment.lookup("jcr/repository");

            return repository.login(new SimpleCredentials("username", "password".toCharArray()));

        } catch (NamingException e) {
            e.printStackTrace();

        } catch (RepositoryException e) {
            e.printStackTrace();
        }

        return null;
    }

    public final void sessionLogout(Session session) {
        if (session != null) {
            session.logout();
        }
    }

    public void addDocument(DocumentJcr documentJcr) {

        Session session = sessionLogin();
        try {

            ByteArrayOutputStream out = new ByteArrayOutputStream();
            ObjectOutputStream obj = new ObjectOutputStream(out);
            obj.writeObject(documentJcr);
            obj.flush();
            InputStream ins = new ByteArrayInputStream(out.toByteArray());

            Node root = session.getRootNode();

            if (!root.hasNode("repozytorium/dokument")) {
                Node repozytorium = root.addNode("repozytorium");
                Node document = repozytorium.addNode("dokument", "nt:unstructured");

                document.addMixin("mix:versionable");
                document.setProperty("object", ins);

                session.save();

            } else {

                Node child = root.getNode("repozytorium/dokument");
                child.checkout();
                child.setProperty("object", ins);
                session.save();
                child.checkin();

            }

        } catch (Exception e) {
            // TODO: handle exception

        } finally {
            sessionLogout(session);
        }
    }

    public List getDocumentJcr() {
        Session session = sessionLogin();

        List listDocument = new ArrayList();
        try {

            Node root = session.getRootNode();
            Node node = root.getNode("repozytorium/dokument");

            VersionHistory versionHistory = node.getVersionHistory();
            VersionIterator versionIterator = versionHistory.getAllVersions();

            while (versionIterator.hasNext()) {
                Version version = versionIterator.nextVersion();
                NodeIterator nodeIterator = version.getNodes();

                while (nodeIterator.hasNext()) {

                    Node versionedNode = nodeIterator.nextNode();

                    if (versionedNode.hasProperty("object")) {

                        InputStream in = versionedNode.getProperty("object").getStream();
                        ObjectInputStream ois = new ObjectInputStream(in);

                        DocumentJcr document = (DocumentJcr) ois.readObject();
                        listDocument.add(document);
                    }
                }
            }

        } catch (Exception e) {
        } finally {
            sessionLogout(session);
        }
        return listDocument;
    }
}

Jak widzimy w przykladzie dodajemy wezeł repozytorium do głównego wezła a następnie do niego kolejny “document” w ktorym będziemy zapisywać nasz prosty dokument. Ma on typ “nt:unstructured”, który cechuje się brakiem jakichkolwiek wymagań odnośnie swojej wewnętrznej budowy. Możemy więc tworzyć dowolną strukturę takiego węzła. Następnie dodajemy do węzła typ “mix:versionable”,co daje możliwość wersjonowania tego węzła (repozytorium przechowuje jego historie zmian). Podczas odczytu z tego węzła, dostaniemy ostatnią wersje dokumentu. Jednak możemy przeglądać wszystkie wersje naszego dukumentu iterując po VersionHistory dla konkretnego węzła. W naszym przykładzie cały czas odwołujemy się do jednego dokumentu (węzła). Wprowadzamy w nim zmiany, a następnie wszystkie wersje dokumentu wyświetlamy na stronie. Każdy węzeł posiada pola “property” w których przechowujemy informacje w naszym przypadku obiekt DocumentJCR.

W pliku web.xml dodajemy wpis:





     ...
	
		Content Repository
		jcr/repository
		
			javax.jcr.Repository
		
	
     ...

Jeszcze kontroler i apliakcja gotowa

package pl.j2ee.jcr_example.controller;

public class MainController extends SimpleFormController {

    private IDocumentService documentService;

    public MainController() {
        setCommandClass(DocumentJcr.class);
    }

    @Override
    protected Map referenceData(HttpServletRequest request, Object command, Errors errors)
            throws Exception {

        HashMap map = new HashMap();

        map.put("documentList", documentService.getDocumentJcr());

        return map;
    }

    protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command,
            BindException errors) throws Exception {

        DocumentJcr doc = (DocumentJcr) command;
        doc.setDate(new Date());
        documentService.addDocument(doc);

        return new ModelAndView("redirect:/main.action");
    }

    @Autowired
    public void setDocumentService(IDocumentService documentService) {
        this.documentService = documentService;
    }
}

Oczywiscie to jest tylko mala czastka możliwosci jakie posiada Jackrabbit. Przedstawiłem jedynie jedną z możliwości czyli wersjonowanie. Warte zaznaczenia są jeszcze możliwość blokowania dostępu do danego węzła czy możliwość śledzenia zmian w repozytorium.
Nasuwa się wniosek, że jeżeli mamy do czynienia z aplikacją do zarządzania treścią, napewno warto rozważyc mozliwość wykorzystania do tego biblioteki Jackrabbit.

Kod źródłowy aplikacji do pobrania tutaj.

JasperReports i Spring

Michał Gołacki — Fri, 30 May 2008 08:59:41 +0000

Jasper Reports jest to biblioteka pozwalająca na generowanie raportów. Jej głównym założeniem jest wsparcie dla tworzenia gotowych do druku dokumentów. Biblioteka jest w całości napisana w Javie, pozwala to na użycie jej w dowolnej aplikacji Javy. Jasper oferuje eksport raportów do szeregu popularnych formatów takich jak: PDF, XML, HTML, CSV, XLS, RTF, TXT. W tym artykule zajmę się wykorzystaniem go do wygenerowania raportu w połączeniu ze Spring’iem.

Szablon raportu

Przede wszystkim potrzebny nam będzie plik z szablonem raportu, który wypełnimy danymi. Do jego przygotowania użyłem iReport. iReport jest edytorem WYSIWYG służącym do przygotowania pliku jrxml. Pozwala na ustalenie wszystkich parametrów szablonu, takich jak: rozmieszczenie pól, czcionki i wiele innych. iReport jest w stanie generować raporty samodzielnie, korzystając z wielu różnych źródeł danych. Możliwości samego iReport są bardzo duże i nie będę poruszał tu wszystkich aspektów jego użycia, jednak postaram się przedstawić w skrócie zastosowane przeze mnie elementy. W szablonie pojawiają się pola, nazwane tak samo jak pola obiektu reprezentującego pojedynczy wiersz. Jasper wykorzysta metody getXXX, aby uzyskać dostęp ich wartości. Elementy zlokalizowane są tworzone z wykorzystaniem parametru REPORT_RESOURCE_BUNDLE, który pełni tu rolę MessageSource. Trzecia grupa elementów to nasze własne parametry, które zostaną przekazane w modelu. Ostatnia to zmienne, które służą na przykład do numerowania stron lub wierszy. Dokument jest podzielony na kilka sekcji. W tym zostało wykorzystane pięć z nich. Sekcja title, wyświetlana tylko na pierwszej stronie, zawiera jak sama nazwa wskazuje tytuł raportu, oczywiście w każdej sekcji możemy dowolnie zdefiniować wyświetlanie informacje, jednak należy pamiętać, że nie każda z nich zachowuje się tak samo. Sekcja pageHeader zawiera nagłówek wyświetlany na każdej stronie. W naszym przypadku będzie to data utworzenia raportu. Sekcja columnHeader zawiera zwykle nagłówki kolumn. W detail umieszczane są kolejne linie. Linie nie muszą być tylko liniami, mogą to być dużo bardziej skomplikowane konstrukcje. Dla każdego z wierszy (obiektu zawierającego dane) zostanie utworzona kopia takiego “wiersza”. Ostatnią sekcją użytą w naszym przykładowym raporcie jest pageFooter, w której umieścimy numerację stron. Plik jrxml kompilujemy do formatu jasper i umieszczamy w projekcie.

Spring

Tu przede wszystkim potrzebny jest widok. W tym przypadku wykorzystamy klasę JasperReportsPdfView, która pozwoli nam na wygenerowanie raportu w postaci pliku PDF.

W celu uzyskania raportów w innych formatach, będziemy musimy użyć odpowiadających im klas z pakietu org.springframework.web.servlet.view.jasperreports.

Musimy zdefiniować także messageSource. Zostanie on wykorzystany przy generowaniu zlokalizowanych raportów.


  
    
      /WEB-INF/i18n/messages

Wykorzystanie ReloadableResourceBundleMessageSource pozwoli na zastosowanie kodowania UTF-8 w plikach lokalizacyjnych.

Do generowania raportów w różnych językach przydadzą się nam localeResolver i localeChangeInterceptor

Kolejne kroki to zdefiniowanie kontrolera, który obsłuży nasze zapytanie oraz serwisu, który dostarczy nam danych. W tej aplikacji serwis jest tylko zaślepką i zwraca nam statycznie zdefiniowane wartości w oczekiwanej przez nas ilości.

Kontroler opakowuje wiersze w raporcie jako JRBeanCollectionDataSource i przekazuje je do widoku. Jasper już sam zajmie się wpisaniem ich w odpowiednie miejsca i wygenerowaniem właściwej liczby linii. Do modelu można dodać również inne parametry, takie jak chociażby data utworzenia raportu, czy użytkownik, który go wygenerował. Zwrócenie raportu do przeglądarki odbywa się podobnie jak przy zwracaniu dowolnego innego widoku, czyli przez utworzenie nowego obiektu ModelAndView.

protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception
{
  ReportFormDTO dto = (ReportFormDTO)command;
  Map model = new HashMap();
  List list = salesDataService.getSalesData(dto.getValue());
  model.put(“generatedOn”, new Date());
  model.put(“JRDataSource”, new JRBeanCollectionDataSource(list));
  return new ModelAndView(pdfView,model);
}

Efektem będzie wygenerowanie zlokalizowanego dokumentu PDF zawierającego nasze dane. Aktualne locale pobrane zostanie z naszego localeResolver. Warto zauważyć, że lokalizowane są nie tylko teksty, ale także liczby i daty.

Pozostaje nam jeszcze spięcie wszystkiego w Spring’u i możemy już generować nasze raporty.

Z własnego doświadczenia zauważyłem, że dla każdego formatu pliku najlepiej jest przygotować osobny plik szablonu, ze względu na to iż na przykład Excel nie poradzi sobie poprawnie z separatorami tysięcy. Dokument przygotowany jako piękny pdf może być zupełnie bezużyteczny jako xls i odwrotnie.

Podsumowując moim zdaniem jest to doskonałe narzędzie do przygotowania dokumentów PDF, które będą wyglądały dokładnie tak jak sobie tego życzymy z dokładnością do pojedynczych pikseli, mimo iż zawarta w nich treść będzie generowana dynamicznie. Jak widać wygenerowanie pojedynczego raportu nie wymaga zbyt wiele kodu i polega głównie na przygotowaniu odpowiedniego szablonu.

Cały kod źródłowy aplikacji możecie znaleźć tu.

Stripes framework

Piotr Święciak — Wed, 16 Apr 2008 09:07:05 +0000

Stripes jest frameworkiem wspomagającym implementowanie warstwy prezentacji w aplikacjach webowych. Jest podobny do znanego wszystkim frameworka Struts. Jednak Stripesy nie wymagają konfigurowania warstwy widoku w plikach xml co w przypadku poznawania nowego frameworka jest kłopotliwe i wymaga więcej czasu. W tym wypadku cała konfiguracja obsługiwana jest za pomocą adnotacji wprowadzonych w Javie 5.

Jako przykład przedstawiający kilka możliwości tego frameworka stworzymy prostą aplikację webową, która służyć będzie do zarządzania książkami w bibliotece (dodawanie nowych pozycji, usuwanie, edycja). Do stworzenia projektu będzie potrzebny właściwie tylko Maven2 oraz serwer aplikacji w naszym wypadku wystarczy Tomcat (oczywiście pomocny będzie również Eclipse choć nie jest konieczny).

Zaczynamy oczywiscie od wygenerowania szkieletu projektu :

mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=pl.jcommerce.biblioteka -DartifactId=Stripes-Biblioteka

Następnie jeżeli chcemy korzystać z Eclipse w katalogu projektu wykonujemy instrukcje mvn eclipse:eclipse i importujemy projekt w Eclipse.

Kolejnym krokiem jest konfiguracja pliku pom.xml


	4.0.0
	pl.jcommerce.biblioteka
	Stripes-Biblioteka
	war
	1.0-SNAPSHOT
	stripesexample Maven Webapp
	http://maven.apache.org
	
		package
		stripesexample
		
			
				org.apache.maven.plugins
				maven-compiler-plugin
				
					utf8
					1.6
					1.6
				
			
		
	
	
		
			net.sourceforge.stripes
			stripes
			1.4.3
		
		
			javax.servlet
			jstl
			1.2

Teraz zajmiemy się konfiguracją deskryptora aplikacji webowej. W przypadku naszej aplikacji wystarczy najprostsza konfiguracja czyli ustawienie Stripes Filter oraz Stripes Dispatcher.




	
		Stripes Filter
		StripesFilter
		
			net.sourceforge.stripes.controller.StripesFilter
		
	
	
		StripesFilter
		*.jsp
		REQUEST
	
	
		StripesFilter
		StripesDispatcher
		REQUEST
	
	
		StripesDispatcher
		
			net.sourceforge.stripes.controller.DispatcherServlet
		
		1
	
	
		StripesDispatcher
		*.action

Nasza aplikacja ma służyć do zarządzania książkami, dlatego zaczniemy od stworzenie modelu danych.

package pl.jcommerce.entity;
import java.util.Date;

public class Book {

	private int id;
	private String title;
	private String author;
	private Date date;
	private int amount;

	public String getTitle() {
		return title;
	}

	public void setTitle(String title) {
		this.title = title;
	}

	public String getAuthor() {
		return author;
	}

	public void setAuthor(String author) {
		this.author = author;
	}

	public Date getDate() {
		return date;
	}

	public void setDate(Date date) {
		this.date = date;
	}

	public int getAmount() {
		return amount;
	}

	public void setAmount(int amount) {
		this.amount = amount;
	}

	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

}

W końcu przyszedł czas na warstwą prezentacji, która zarządzana będzie przez framework Stripes. Kontrolery będą odpowiedzialne za akcje wykonywane przez użytkownika. Pierwszy z nich będzie miał za zadanie przekierowanie i wyświetlenie strony startowej, oraz stworzenie listy książek.
Ponieważ nie korzystamy z bazy danych, dlatego wykorzystamy do tego celu statyczną listą książek, na której będziemy operować.

package pl.jcommerce.action;

import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;

@UrlBinding("/index.action")
public class IndexActionBean implements ActionBean {

	private ActionBeanContext context;

	public ActionBeanContext getContext() {
		return context;
	}

	public void setContext(ActionBeanContext context) {
		this.context = context;
	}

	@DefaultHandler
	public Resolution getListBooks() {
		return new ForwardResolution(ListBooksActionBean.class);
	}

}

Kontroler ten jak i wszystkie inne implementuje interface ActionBean, ponieważ każdy kontroler musi zawierać pole context (informacje o aktualnym stanie aplikacji) typu ActionBeanConext. Adnotacja @UrlBinding(”/index.action”) przypisuje do kontrolera nazwę, według której będziemy sie odwoływać ze stron jsp. Kolejną adnotacją znajdującą się w tym kontrolerze jest @DefaultHandler. Metoda poprzedzona tą adnotają wykonana zostanie jeżeli będziemy się odwoływać do danego kontrolera, a nie podamy nazwy zdarzenia, które ma zostać obsłużone. W naszym wypadku w momencie odwołania sie do tego kontrolera zostaje wywołana domyślna metoda, która z kolei przekierowuje nas do kolejnego kontrolera ListBooksActionBean.

package pl.jcommerce.action;

import java.util.HashMap;
import java.util.Map;

import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.HandlesEvent;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;
import pl.jcommerce.entity.Book;

@UrlBinding("/listBooks.action")
public class ListBooksActionBean implements ActionBean {

	public static Map books = new HashMap();

	private ActionBeanContext context;

	public ActionBeanContext getContext() {
		return context;
	}

	public void setContext(ActionBeanContext context) {
		this.context = context;
	}

	@DefaultHandler
	public Resolution getListBooks() {
		return new ForwardResolution("/jsp/listBooks.jsp");
	}

	@HandlesEvent("addBook")
	public Resolution addBook() {
		return new ForwardResolution(AddBookActionBean.class);
	}

	public Map getBooks() {
		return books;
	}

	public void setBooks(Map books) {
		ListBooksActionBean.books = books;
	}

}

W tym kontrolerze widzimy adnotację @HandlesEvent(”addBook”), która powoduje przypisanie nazwy zdarzenie do metody. Jeżeli przed metodą w kontrolerze nie użyjemy tej adnotacji domyślne zdarzenia nazywają się tak samo jak nazwa metody. Ostatni kontroler w naszej aplikacji odpowiada za dodawanie i edycje książek.

package pl.jcommerce.action;import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.HandlesEvent;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;
import net.sourceforge.stripes.validation.LocalizableError;
import net.sourceforge.stripes.validation.Validate;
import net.sourceforge.stripes.validation.ValidateNestedProperties;
import net.sourceforge.stripes.validation.ValidationErrors;
import net.sourceforge.stripes.validation.ValidationMethod;
import pl.jcommerce.entity.Book;

@UrlBinding("/addBook.action")
public class AddBookActionBean implements ActionBean {

	private static final String SAVE_EVENT = "save";

	private static int counter;

	@ValidateNestedProperties( {
	@Validate(field = "title", on = SAVE_EVENT, required = true, minlength = 3, maxlength = 15),
	@Validate(field = "author", on = SAVE_EVENT, required = true, maxlength = 25),
	@Validate(field = "date", on = SAVE_EVENT, required = true, maxlength = 25),
	@Validate(field = "amount", on = SAVE_EVENT, required = true) })
	private Book book;

	private ActionBeanContext context;

	public ActionBeanContext getContext() {
		return context;
	}

	public void setContext(ActionBeanContext context) {
		this.context = context;
	}

	public Book getBook() {
		return book;
	}

	public void setBook(Book book) {
		this.book = book;
	}

	@DefaultHandler
	public Resolution view() {
		return new ForwardResolution("/jsp/addBook.jsp");
	}

	@HandlesEvent(SAVE_EVENT)
	public Resolution save() {
		if (book.getId() == 0) {
			book.setId(++counter);
		}
		ListBooksActionBean.books.put(book.getId(), book);
		return new ForwardResolution(ListBooksActionBean.class);
	}

	@HandlesEvent("edit")
	public Resolution edit() {
		book = ListBooksActionBean.books.get(book.getId());
		return new ForwardResolution("/jsp/addBook.jsp");
	}

	@HandlesEvent("delete")
	public Resolution delete() {
		ListBooksActionBean.books.remove(book.getId());
		return new ForwardResolution(ListBooksActionBean.class);
	}

	@ValidationMethod(on = "save")
	public void validateSave(ValidationErrors errors) {
		if (book.getId() == 0) {
			for (Book s : ListBooksActionBean.books.values()) {
				if (book.getTitle().equals(s.getTitle())) {
					errors.add("book.title", new LocalizableError("er.book.title"));
					getContext().setValidationErrors(errors);
				}
			}
		}
	}

}

W naszym ostatnim kontrolerze widzimy adnotacje związane z walidacją danych. Jeżeli mamy do czynienia z obiektem możemy walidować wszystkie jego pola oraz okreslić w przypadku jakich akcji dane pola maja być walidowane. W naszym przypadku wszystkie pola bedą sprawdzane w czasie zgłoszenia zdarzenia „save”. Adnotacja @ValidateMethod(on=”save) powoduje wywołanie tej metody walidującej jedynie podczas zgłaszania zdarzenie “save”.

Walidacja oraz internacjonalizacja opisana jest w pliku StripesResources .properties

validation.required.valueNotPresent=Pole {0} jest wymagane polem
validation.minlength.valueTooShort=Pole {0} wymaga wpisania conajmniej {2} znakow
validation.maxlength.valueTooLong=Pole {0} moze miec max {2} znaki

converter.number.invalidNumber=Warto\u015B\u0107 ({1}) wprowadzona w polu "{0}" musi by\u0107 liczb\u0105
converter.date.invalidDate=Warto\u015B\u0107 ({1}) wprowadzona w polu "{0}" musi by\u0107 prawid\u0142ow\u0105 dat\u0105

book.title=Tytul
book.amount=Liczba dostepnych
book.date=Data wydania
book.author=Autor
er.book.title=Ksiazka o podanym tytule znajduje sie juz w bibliotece

Wszystkie kontrolery już gotowe a więc teraz czas na strony jsp:

index.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>

listBooks.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"%>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%>
<%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes.tld"%>


	
		Stripes example
	
	
		
			
			
					
				
					
					
					
					
				
				
						${book.value.title}
						${book.value.author}
						
						${book.value.amount}
						
							Edit 
						
						
							Delete

addBook.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"%>
<%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes.tld"%>





Stripes example



	
	
		
			:
			
			
		
		
			:
			
			
		
		
			:
			
			
		
		
			:

Mamy już wszystkie pliki potrzebne nam w aplikacji zatem wykonujemy polecenie mvn install i plik war wrzucamy na serwer.
Mam nadzieje, że ten krótki artykuł choć trochę przybliżył zasadę działania tego frameworka. Oczywiście możliwości jego są dużo większe niż przedstawiłem w tym artykule, dlatego na temat jego wszystkich możliwości odsyłam na stronę domową frameworka.

Pluto, jetty i portlety.

Karol Siczek — Wed, 26 Mar 2008 12:40:56 +0000

Tytułem wstępu, czyli kto i co.

Witajcie.
To mój debiut na j2ee.pl i mam nadzieję, że będzie początkiem dłuższej przygody. W tym poście postaram się opisać jak, w kilku krokach, stworzyć i uruchomić prosty portlet używając mavena2 i kilku jego pluginów. Dlaczego to jest takie fajne? Ponieważ wystarczy wpisać mvn jetty:run i można testować swój portlet. Trwa to kilka sekund, więc oszczędność czasu może być znacząca w porównaniu z restartem jBoss Portal, lub Liferay. Ponieważ pomysłem było napisanie prostego howto, części teoretycznej niestety nie będzie. Nie znajdziecie tutaj co to jest portal/kontener portletów, ani nawet sam portlet. Zainteresowane osoby odsyłam do specyfikacji JSR168 i wszechwiedzącej sieci.

Co będzie potrzebne?

Właściwie tylko maven2 i jakiś edytorek kodu (zakładam, że w miarę nową jave każdy ma). Razem z m2 będziemy używać pluginów jetty i pluto. Jetty jest implementacją serwera webowego, natomiast pluto jest referencyjną implementacją specyfikacji portletów.

Tworzymy projekt.

Do wygenerowania szkieletu projektu wykorzystamy archetyp maven-archetype-portlet:
mvn archetype:create -DgroupId=pl.j2ee.portlet -DartifactId=portlet-example -DarchetypeArtifactId=maven-archetype-portlet
Jeśli zamierzamy używać Eclipse’a, przechodzimy do katalogu projektu i wykonujemy: mvn eclipse:eclipse

Kolejną rzeczą, jaką należy wykonać, jest modyfikacja pom.xml projektu. Proponuję stworzyć oddzielny profil, np. pluto-embedded:


  pluto-embedded
  [...]

i w nim dodać wpisy dla pluginów:


  org.mortbay.jetty
  maven-jetty-plugin

oraz


  org.apache.pluto
  maven-pluto-plugin
  
    
      generate-resources
      
        assemble

Goal assemble posłuży do wygenerowania web.xml z odpowiednią konfiguracją i mapowaniem serwletu org.apache.pluto.core.PortletServlet. Kolejną rzeczą jest konfiguracja pluginu jetty:


  ${project.build.directory}/pluto-resources/web.xml
  src/main/webapp/WEB-INF/jetty-pluto-web-default.xml
  
    
      org.apache.pluto.embedded.portletId
      MyPortlet

Tag wskazuje na miejsce, z którego jetty zaczyta sobie deskryptor web.xml-a (wygenerowany wcześniej przez pluto).
Ponieważ pluto korzysta z pliku src/main/webapp/WEB-INF/web.xml do generowania pliku wynikowego, a my nie będziemy potrzebować dodatkowych mapowań, usuwamy to co stworzył nam archetyp i zostawiamy ten plik w postaci:

Kolejna rzecz, której potrzebujemy, to konfiguracja parametrów kontekstu, filtrów, serwletów, mapowań itp. Najwygodniej jest użyć gotowego pliku jetty-pluto-web-default.xml, który można znaleźć w archiwum maven-jetty-pluto-embedded-1.0.jar, lub w załączonych źródłach projektu.

Przejdźmy więc do edycji pliku portlet.xml. Jego zawartość zawiera większość potrzebnych informacji, ale zawiera też błędy – tag jest nieprawidłowo stworzony przez archetyp i należy go nieznacznie zmodyfikować wpisując poprawną nazwę klasy portletu. Zmieniamy także wartość tagu tak, aby odpowiadała property org.apache.pluto.embedded.portletId z pom.xml projektu. Na chwilę jeszcze wróćmy do pom.xml projektu i uzupełnijmy zależności:


  org.mortbay.jetty
  jetty
  6.1.5
  provided


  org.mortbay.jetty
  jsp-2.1
  6.1.5
  provided


  com.bekk.boss
  maven-jetty-pluto-embedded
  1.0

Aby sprawdzić, czy wszystko zrobiliśmy dobrze, przechodzimy do katalogu projektu i wpisujemy:

mvn jetty:run -P pluto-embedded

Gdy uruchomi nam się serwer, wpisujemy w przeglądarce http:localhost:8080/portlet-example/pluto/index.jsp i voilà!
Jeśli komuś nie odpowiada port 8080 na którym słucha serwer, może zmodyfikować konfigurację pluginu. Teraz, gdy już widzimy, że wszystko w miarę fajnie się prezentuje zrobimy prosty formularz powitalny: W pliku normal.jsp zamiast powitania mavena, stwórzmy formularz:


  
    Hello 
  
  
    
      
        First name: 
        Last name:

Następnie w klasie MyPortlet dodajemy prostą metodę:

public void processAction(ActionRequest request, ActionResponse response) throws PortletException, IOException {
	if(request.getParameter("firstName") != null && request.getParameter("lastName") != null)
		response.setRenderParameter("fullName", request.getParameter("firstName") + " " + request.getParameter("lastName"));
}

Podsumowanie.

Ponieważ, jak już wspomniałem, jest to mój pierwszy post na j2ee.pl (dzięki Michał :) ), będę wdzięczny za wszystkie komentarze. Piszcie, co Wam się podobało, co nie i czy takie how-to do czegoś Wam się przydało. Może coś jest niejasne, albo czegoś brakuje…W następnym poście postaram się dodać testy jwebunit-owe i pokazać w jaki sposób można taki formularz potraktować testami jednostkowymi.

Źródła:

Pluto, jetty i portlety-źródła, jetty, pluto, portletwork,


${book.value.title}	${book.value.author}		${book.value.amount}	Edit	Delete