Recenzja “Programming Groovy: Dynamic Productivity for the Java Developer”
W dniu dzisiejszym skończyłem czytać książkę Programming Groovy: Dynamic Productivity for the Java Developer, książka jest tak dobra, że zasługuje na recenzję, którą oczywiście napisałem i umieściłem tutaj, dla wszystkich którzy po jej przeczytaniu w dalszym ciągu się wahają, polecam recenzję Neal’a Ford’a na Amazon. Książki nie musicie kupować, jest ona dostępna w biblioteczce Polish JUG. Na zakończenie jeszcze raz gorąco zachęcam do przeczytania.
Kilka powodów dla których warto wybrać Groovy’ego
W poprzednim wpisie rozwodziłem się nad wyborem mojego kolejnego języka programowania. Niezależnie od Waszych opini czy wybór był słuszny, a argumentacja właściwa postanowiłem dziś przedstawić kilka powodów dla których warto zainteresować się językiem Groovy. Ponieważ moim zdaniem przykład jest zdecydowanie więcej wart niż czysta teoretyczna dywagacja, stąd przedstawię kilka przykładów kodu w Groovy które moim zdaniem mogą przekonać Was do poświęcenia większej ilości czasu temu językowi.
1. Pętle
Poniższy przykład wypisuje w kolejnych liniach liczby od 0 do 9:
println it
}
Liczby te możemy również wypisać w następujący sposób:
println it
}
2. Wypisywanie wartości zmiennych w łańcuchu znaków
Jeśli chcemy wstawić wartość zmiennej w łańcuchu znaków możemy to zrobić w następujący sposób:
println “Aktualne wywołanie ma numer: ${it}, pozostało jeszcze ${3 - it} wywołań”
}
Wywołanie tego kodu sprawi, że otrzymamy następujący wynik:
Aktualne wywołanie ma numer: 2, pozostało jeszcze 1 wywołań
Aktualne wywołanie ma numer: 3, pozostało jeszcze 0 wywołań
3. Closures
Przygotujmy sobie metodę która pozwoli na wykonanie kolejno n jednakowych operacji:
1.upto(n) {
operationClosure(it);
}
}
A teraz wykonajmy pięciokrotnie wypisanie aktualnej wartości licznika wywołań:
println it
}
W wyniku otrzymamy:
2
3
4
5
4. Operacje na kolekcjach
Zdefiniujmy następującą mapę:
Wypiszmy teraz liczbę członków na podstawie mapy:
println “${key} ma ${value} członków”
}
W wyniku wykonania powyższego fragmentu otrzymamy:
Polish JUG ma 398 członków
O proszę, Polish JUG ma już 398 członków!
5. Tworzenie XML
Utwórzmy XML na podstawie zdefiniowanej wcześniej mapy:
builder.jugi{
members.each{ key, value ->
jug(nazwa: key, czlonkowie: value)
}
}
W wyniku wykonania otrzymamy następujący XML:
<jug nazwa=‘Warszawa JUG’ czlonkowie=‘268′ />
<jug nazwa=‘Polish JUG’ czlonkowie=‘398′ />
</jugi>
Prawda, że łatwe i bardzo przyjemne?
Oczywiście to nie wszystko, Groovy posiada dużo większe możliwości a przedstawione powyżej przykłady to tylko drobna namiastka tego co może Was spotkać przy zgłębianiu tajemnic tego języka.
Więcej o Groovy i Grails w kolejnych wpisach.
Wybór nowego języka programowania
Od pewnego czasu myślałem o poznaniu kolejnego języka programowania, przez ostatnie miesiące przyglądałem się kilku: Scala, Ruby, Groovy, Python, C#. Starałem się specjalnie nie szukać języka, który miałby swoją implementację na platformie Java, jednak istnienie takiej implementacji mimo wszystko było istotnym atutem, stąd też początkowy zbiór ograniczyłem do języków powiązanych z platformą Java: Scala, Ruby (JRuby), Groovy, Python (Jython).
Po tym pierwszym etapie selekcji przyszedł czas na przeczytanie artykułów i różnych tutoriali dotyczących wcześniej przedstawionych języków. O ile składnia Groovy’ego jest bardzo zbliżona do Javy, a właściwie to w wielu przypadkach można przekopiować kod Javy do pliku z rozszerzeniem .groovy i uruchomić bez dodatkowych modyfikacji, o tyle poznanie składni pozostałych języków wymagało większego wysiłku, dzięki temu Groovy zapunktował u mnie jako język na naukę którego będę musiał poświęcić mniej czasu 
Trzeci etap podejmowania wyboru skupiła się na pytaniu: “Czy język ma być dynamiczny?”, po zachwalaniu przez Wiktora Gworka języków dynamicznych postanowiłem dać szansę trójce: Groovy, Ruby (JRuby), Python (Jython).
Wybór już znacznie uproszczony, zostało 3 z 5
Czas na dalszą eliminację… nauka nowego języka powinna być przyjemna, nie jestem tradycjonalistą i zawsze jestem otwarty na nowe propozycje ale w tym wypadku chciałem używać narzędzi do których jestem przyzwyczajony i o których wiem, że są najwyższej jakości, a gwarancję taką dawał mi IntelliJ IDEA, do którego dostępne są dwie firmowane przez JetBrains wtyczki: JetGroovy oraz IntelliJ Ruby Plugin, wtyczka do Pythona również istnieje niestety nie jest ona regularnie aktualizowana… w ten sposób ograniczyłem wybór do Groovy’ego i Ruby’ego.
Nadszedł czas na porównanie frameworków do tworzenia aplikacji webowych, zapewne wszyscy wiedzą, że w świecie Ruby’ego królują Railsy, podobnie jest w przypadku Groovy’ego dla którego głównym frameworkiem webowym są wzorowane na Railsach Grailsy. Obydwa frameworki cechują się podejściem convention over configuration, jednakże cechą która zadecydowała wyborze Grails‘ów jest ich powiązanie ze Spring‘iem i Hibernate. Powiązanie to nie było dla mnie bez znaczenia, oba frameworki są mi znane, oba też stanowią niekwestionowany standard w swoich kategoriach.
Jak więc widzicie, w sposób mniej lub bardziej słuszny wybrałem język za którego rozpoznanie zabrałem się ostatnio, jest nim Groovy. Aktualnie kończę czytać świetną książkę Programming Groovy (zachęcam do wypożyczenia z biblioteczki Polish JUG), której recenzję umieszczę w najbliższym czasie, zapoznałem się również wstępnie z Grails’ami, a nawet stworzyłem swoje pierwsze aplikacje webowe napisane w Grails!
Na koniec chciałem jeszcze dodać, iż spotkała mnie miła niespodzianka dotycząca NetBeans, czyli drugiego środowiska które używam, otóż powstaje plugin do NetBeans pozwalający na tworzenie aplikacji w Groovy i Grails, więcej szczegółów na jego temat znajdziecie na oficjalnej stronie wtyczki.
Spring i wstrzykiwanie zależności między bean’ami o różnych zasięgach.
Na pewno wszyscy z Was znają framework (rusztowanie aplikacyjne? LOL) Spring, więc nieobce jest wam hasło Dependency Injection. Wielu z Was codziennie korzysta z dobrodziejstw jakie daje DI, a niektórzy nie są w stanie się bez tego obejść.
Jak wiemy w Springu dostępnych jest kilka zasięgów które określają cykl życia bean’ów (ziaren), bean’y te mogą być od siebie wzajemnie zależne.
Uzależnienie jednego bean’a od drugiego jest w Springu dziecinnie proste i polega na napisaniu kawałka XML:
<beans xmlns=“http://www.springframework.org/schema/beans”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd”>
<bean id=“firstBean” class=“org.holewa.FirstBean”/>
<bean id=“secondBean” class=“org.holewa.SecondBean”>
<property name=“firstBean” ref=“firstBean”/>
</bean>
</beans>
Gdzie postać klasy FirstBean jest następująca:
public class FirstBean {
}
Klasa SecondBean zawiera akcesory dzięki którym zostanie wstrzyknięta zależność od FirstBean:
public class SecondBean {
private FirstBean firstBean;
public FirstBean getFirstBean() {
return firstBean;
}
public void setFirstBean( FirstBean firstBean ) {
this.firstBean = firstBean;
}
}
To jest chyba najbardziej trywialny przykład zdefiniowania wzajemnych zależności jaki kiedykolwiek wymyślono
Obydwa zdefiniowane powyżej bean’y mają ten sam zasięg, który jest domyślnie zasięgiem singleton.
Sytuacja się jednak nieco komplikuje gdy chcemy stworzyć zależności między bean`ami o różnych zasięgach, tu przykładowo zasięg sesji (session) oraz singleton. O ile wykorzystanie singleton’a w bean’ie o zasięgu sesji jest bezproblemowe (dla wszystkich sesji będzie jeden singleton) o tyle sprawa jest bardziej zagmatwana w przeciwną stronę, bo skąd mamy wiedzieć o którą instancję bean’a chodzi, jest ich przecież wiele (jedna per sesja)? Otóż z pomocą przychodzi nam oczywiście Spring i programowanie aspektowe. Dzięki wykorzystaniu AOP Spring tworzy dynamic proxy które to pośredniczy podczas odwołania się do bean’a. Tak powstałe proxy automagicznie (uwielbiam to określenie :D) odnajduje bean’a znajdującego się w zasięgu sesji z której nastąpiło do niego odwołanie i zwraca do niego referencję. Niestety Spring nie jest aż tak automagiczny jakbyśmy chcieli (a może i dobrze :P), dlatego też trzeba w definicji wybranego bean’a (w tym przypadku tego o zasięgu sesji) zastosować specjalny tag który poinformuje Springa, że odwołania do tego bean’a będą odbywać się dzięki zastosowaniu dynamic proxy.
Robi się to następująco:
<beans xmlns=“http://www.springframework.org/schema/beans”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=“http://www.springframework.org/schema/aop”
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd”>
<bean id=“sessionData” scope=“session”
class=“org.holewa.SessionData”>
<aop:scoped-proxy/>
</bean>
<bean id=“singleton” class=“org.holewa.Singleton”>
<property name=“sessionData” ref=“sessionData”/>
</bean>
</beans>
Klasy Singleton i SessionData są tworzone analogicznie do klas FirstBean i SecondBean.
Taka definicja w zupełności wystarcza do tego aby z poziomu singletona odwoływać się do danych (bean’ów) znajdujących się w zasięgu aktualnej sesji.
Prawda, że proste?
Zarobił Jacek, zarobisz i Ty!
Jak zapewne część z Was wie, ostatnio odbył się konkurs na najlepszy wpis na blogu o NetBeans 6.1, mieliśmy wśród zwycięzców jednego rodaka - Jacka Laskowskiego (ciekawe dlaczego mnie to nie dziwi :P), Jacek zgarnął w ten sposób swoje 500 dolców ale musiał się przy tym trochę napisać 
Okazja do zarobienia takiej samej kwoty pojawia się ponownie, przy czym tym razem nie trzeba się aż tyle wysilać 
Zapytacie pewnie jak to możliwe? Trzeba tylko wziąć udział w konkursie organizowanym przez The GlassFish Awards Program i zgłaszać bugi. Tak, nie mylicie się - za zgłoszenie buga który kwalifikuje się do czołowej setki otrzymujecie $500!
Zostań Sun Campus Ambassadorem
Wszystkich zainteresowanych pozycją Sun Campus Ambassadora we Wrocławiu odsyłam do informacji umieszczonych na blogu Pawła Szulca.
Prezentacja na Uniwersytecie Gdańskim
Miałem się wstrzymać z pisaniem czegokolwiek na blogu, jednak jutro wybieram się do Gdańska zaprezentować JavaFX, tak, tak - znowu JavaFX Właściwie to ten topic jest teraz (po JavaOne) bardzo trendy, gdyż w internecie można znaleźć bardzo dużo burzliwych dyskusji na temat JavaFX (świat Javy podzielił się na 2 fronty :D). Mam nadzieję, że i jutro nie zabraknie dyskusji zwłaszcza, że chciałem pewną, dość sporą ilość czasu przeznaczyć na luźną rozmowę na tematy Javowe (nie tylko JavaFX) takie jak JUG`i, community i rzeczy które się dzieją w naszej polskiej społeczności. Myślę, że może to być dość ciekawe, choćby dlatego, że zazwyczaj prelegenci rozmawiają na tematy związane tylko z prezentacją, a jeszcze inni zawsze uciekają na pociąg :P:P:P
Oto namiary:
Instytut Informatyki,Uniwersytet Gdański
ul. Wita Stwosza 57 Gdańsk,
aula nr 2. godzina 16:00
Wszystkich gorąco zapraszam!
NetBeans RoadShow
W dniach 11-13 kwietnia odbędzie się w Polsce NetBeans RoadShow, które wchodzi w skład NetBeans WorldTour 2007 - 2008. W ramach tego cyklu, w miastach takich jak Kraków, Warszawa i Wrocław odbędą się NetBeans Days, czyli wykłady na temat środowiska developerskiego NetBeans.
Uczestnicząc w spotkaniach będzie można się dowiedzieć wielu ciekawych rzeczy na temat możliwości tego mocno rozwijanego IDE.
Prelegentami podczas NetBeans Days będą zarówno inżynierowie Sun Microsystems z centrum w Pradze jak również nasi rodzimi prelegenci, znani z blogosfery. Również i ja będę miał okazję wystąpić - 13 kwietnia we Wrocławiu podczas mojej prezentacji “Visual Web Development w NetBeans” będziecie mieli okazję dowiedzieć się jak można w prosty i szybki sposób stworzyć aplikacje webowe za pomocą NetBeans. Więcej informacji na temat NetBeans RoadShow uzyskacie na stronie www.netbeansday.pl.
Wszystkich serdecznie zapraszam.
NetBeans, Maven 2 i TestNG
Dziś w południe dostałem takiego oto maila:
“Witam,
Znalazlem mail do Pana na JDN. Od wczoraj walcze z proba polaczenia
TestNG oraz Mavena2 pod Netbeans. Mimo iż w lokalnym repozytorium mam
pakiet TestNG i w przeglądarce projektow w TestLibraries widnieje wpis
testing-4.7-jdk15 to jednak gdy probuje napisac jakikolwiek test to
nie mam dostepu do zadnego klas/adnotacji z biblioteki TestNG - jakby
jej nie bylo na classpath.
Dodam jeszcze ze w przegladarce projektow ikona biblioteki TestNG w
gorjen czesci jest brazowa, podczas gdy ikony innych - szare.
Ponizej zamieszczam fragmenty mojego pliku pom.xml”
Poniżej fragment pliku pom.xml i imię autora maila.
W przerwie między dewelopmentem który przydarzył mi się w te święta, postanowiłem odpowiedzieć na tego maila… na blogu
A więc opiszę po krótko jak skonfigurować prosty projekt w NetBeans 6.1 Beta , do projektu wygeneruję plik pom.xml oraz dodam prościutki test TestNG.
Krok 1 - utworzenie projektu
Utwórzmy najpierw projekt z użyciem NetBeans 6.1 Beta oraz skonfigurujmy go jako projekt Maven 2. W tym celu wybieramy z menu opcję File -> New Project , następnie pojawi nam się takie oto okienko:
Wybieramy w nim opcję Maven -> Maven Project i klikamy Next.
Następny ekran to wybranie archetypu, wybieramy Maven Quickstart Archetype i klikamy Next:
Teraz czas na nadanie groupId i artifactId naszemu projektowi, ja zrobiłem to tak jak widzicie na poniższym obrazku:
Teraz kliamy Finish i proszę, oto nasz projekt:
Składa się on z przykładowego pliku aplikacji (App.java) oraz przykładowego testu (AppTest.java).
Krok 2 - modyfikacja projektu
Ponieważ w tym wpisie interesuje nas TestNG a przykładowy test jest napisany dla JUnit to możemy go usunąć - napiszemy swój od podstaw
Zmodyfikujmy nasz plik pom.xml na następujący (ten plik dotyczy mojego projektu, jeśli nadaliście inne groupId i artifactId to musicie go zmienić analogicznie):
<project xmlns=“http://maven.apache.org/POM/4.0.0″
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”>
<modelVersion>4.0.0</modelVersion>
<groupId>org.holewa</groupId>
<artifactId>test</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>test</name>
<url>http://www.holewa.org</url>
<dependencies>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.6</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>testng.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</build>
</project>
Teraz zmieńmy ustawienia naszego projektu tak aby ustawić dla niego wersję Java zgodną z wersja 1.5, w tym celu wybierzmy z menu kontekstowego naszego projektu opcję Properties, następnie z listy w okienku po lewej stronie opcję Sources i na dole ekranu który nam się ukaże Source/Binary Format ustawmy na 1.5. Możecie to zobaczyć na poniższym obrazku:
NetBeans zmodyfikuje nasz plik pom.xml, dodając do niego taki fragment kodu:
<artifactId>maven-compiler-plugin</artifactId>
<version>RELEASE</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
Dobra, teraz wybierzmy z menu kontekstowego projektu opcję Clean and Build, projekt nam się przebuduje a TestNG dodane jako zależność do naszego pom`a pobierze się z repozytorium Maven 2.
Krok 3 - pisanie testu
Nadszedł czas na nasz test W tym celu tworzymy nowy plik xml o nazwie testng.xml, musi się on znajdować w tym katalogu w którym znajduje się nasz pom.xml, jego zawartość będzie następująca:
<suite name=“Simple test siute”>
<test name=“Simple test”>
<classes>
<class name=“org.holewa.test.SimpleTest”/>
</classes>
</test>
</suite>
Podaliśmy w nim, że nasz projekt zawiera jeden test org.holewa.test.SimpleTest w takim razie czas na jego napisanie
Dodajmy nową klasę do projektu, klikamy prawym przyciskiem myszy na gałąź Test Packages w strukturze projektu, następnie wybieramy opcję New -> Java Class… i dodajemy klasę org.holewa.test.SimpleTest.
Kod znajdujący się w niej powinien mieć następującą postać:
import org.testng.annotations.*;
public class SimpleTest {
@Test
public void simpleTest() {
System.out.println(“My simple test.”);
}
}
Zapiszmy plik. Wybierzmy z menu kontekstowego projektu opcję Clean and Build, w logach które pojawią się na dole w okienku zobaczymy podobną treść:
T E S T S
——————————————————-
Running TestSuite
[Parser] Running:
C:\Documents and Settings\raho\My Documents\NetBeansProjects\test\testng.xml
My simple test.
To znak, że nasz test się wykonał, gdy zmienimy kod metody testowej na:
Dostaniemy podobny komunikat do tego:
T E S T S
——————————————————-
Running TestSuite
[Parser] Running:
C:\Documents and Settings\raho\My Documents\NetBeansProjects\test\testng.xml
My simple test.
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.297 sec <<< FAILURE!
Results :
Failed tests:
simpleTest(org.holewa.test.SimpleTest)
------------------------------------------------------------------------
[ERROR]BUILD FAILURE
------------------------------------------------------------------------
There are test failures.
Gdy wybierzemy teraz z menu kontekstowego projektu opcję Test ukarze nam się wynik w okienku testów JUnit:
Niestety NetBeans nie posiada wtyczki do obsługi testów TestNG, stąd też pojawiające się okienko JUnit ;(
Ponieważ w mailu który był na samym początku padło stwierdzenie “Dodam jeszcze ze w przegladarce projektow ikona biblioteki TestNG w gorjen czesci jest brazowa, podczas gdy ikony innych - szare”, chciałem wytłumaczyć opisaną w nim sytuację.
Zobaczmy na widoku projektu:
A dokładnie bibliotek które się znajdują w zależnościach. Biblioteki zaznaczone kolorowo to bezpośrednie zależności w naszym pom.xml, biblioteki zaznaczone na szaro to biblioteki które są zależnościami do naszych zależności, stąd też inne ich oznaczenie, gdyż nie wprowadzaliśmy ich do projektu bezpośrednio - wprowadził je twórca dodanej przez nas biblioteki ustawiając je jako zależność bez której jego biblioteka nie może funkcjonować. Gdy chcemy ustawić tą bibliotekę tak aby nie była dodana do naszego projektu możemy to zrobić w bardzo łatwy sposób, wystarczy wybrać w menu kontekstowym biblioteki opcję Exclude Dependency a nasz pom.xml zostanie automatycznie zmodyfikowany. Prawda, że łatwe?
DWR czyli “Easy Ajax for Java”
Jeśli ktoś jeszcze jakimś cudem nie wie co to DWR (Direct Web Remoting) to ten wpis jest dla niego, ponieważ postaram się w nim szybko przedstawić co to jest i jak tego można używać
DWR to biblioteka która pozwala z poziomu JavaScript wywołać metody Java oraz vice versa.
W jaki sposób rozpocząć przygodę z DWR? Najprościej pobrać go ze strony i wykonać kilka kolejnych kroków opisanych w tym wpisie.
Krok 1 - dodanie konfiguracji DWR do web.xml.
Chcąc użyć DWR w naszej webowej aplikacji musimy ją najpierw skonfigurować. Na samym początku wprowadzimy ustawienia do naszego pliku web.xml. Dodajmy do niego ten fragment kodu:
<servlet-name>dwr</servlet-name>
<servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>dwr</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
W ten sposób dodaliśmy serwlet DWR do naszej aplikacji. Serwlet ten odpowiada za generowanie plików JavaScript które będą wykorzystane w stronach JSP tworzonych w projekcie.
Krok 2 - Integracja DWR i Spring Framework.
Ponieważ Spring Framework jest szeroko stosowany w projektach opartych o platformę JEE stąd też DWR w łatwy sposób się z nim integruje. Wystarczy dodać do naszego projektu plik zawierający definicję beanów:
<beans xmlns=“http://www.springframework.org/schema/beans”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xmlns:dwr=“http://www.directwebremoting.org/schema/spring-dwr”
xmlns:lang=“http://www.springframework.org/schema/lang”
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.directwebremoting.org/schema/spring-dwr
http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd”>
<dwr:configuration>
<dwr:convert class=“org.holewa.Sample” type=“bean”/>
</dwr:configuration>
<bean id=“dwrFacade” class=“org.holewa.DwrFacade”>
<dwr:remote javascript=“dwrFacade”>
<dwr:include method=“getData”/>
</dwr:remote>
</bean>
</beans>
W powyższym przykładzie zdefiniowaliśmy jeden bean o nazwie dwrFacade oraz udostępniliśmy dla DWR jedną jego metodę o nazwie getData, domyślnie z uwagi na względy bezpieczeństwa wszystkie metody nie są udostępnione.
Podobnie zresztą ma się sprawa z transfer object`ami - musimy dla nich ustawić konwersję czyli sprawić aby DWR mapował odpowiednie struktury danych z poziomu JavaScript na obiekty Java. W naszym przypadku transfer object Sample zawiera tylko jedną zmienną o nazwie parameter.
Krok 3 - dodanie plików JavaScript do naszych stron JSP.
Aby umożliwić wywołanie metod po stronie serwera należy dodać w stronach JSP taki oto fragment kodu:
<script type=‘text/javascript’ src=‘/dwr/engine.js’></script>
<script type=‘text/javascript’ src=‘/dwr/util.js’></script>
Pliki util.js i engine.js to pliki wchodzące w skład DWR, plik dwrFacade.js to plik który został wygenerowany przez serwlet i to właśnie dzięki funkcją które znajdują się w nim możemy wywołać metodę po stronie serwera.
Krok 4 - wywołanie metody po stronie serwera.
W celu wywołania metody po stronie serwera należy wywołać w przeglądarce następującą funkcję:
var to = {
parameter: param
};
dwrFacade.getData(to, function ( str ) {
dwr.util.byId(elementId).innerHTML = str;
});
}
Powyższy kod definiuje funkcję która jako parametry przyjmuje id elementu którego atrybutowi o nazwie innerHTML chcemy przypisać wartość zwróconą przez wywoływaną przez nas metodę getData. Metoda ta przyjmuje jeden parametr który jest obiektem zawierającym pole (atrybut) o nazwie parameter, podczas przesyłania będzie on przekształcony w obiekt Java dla którego wartości atrybutu parameter będzie równa wartości atrybutu parameter którą ustawiliśmy w JavaScript. Funkcja która zostanie wywołana gdy otrzymamy odpowiedź od serwera (pamiętajmy, że występują tu wywołania asynchroniczne dlatego też mamy do czynienia z callback`ami) jest przekazywana do funkcji dwrFacade.getGetData jako drugi parametr.
Jak widzicie zastosowanie DWR jest niezwykle proste - od jego konfiguracji do wywołania zrobiliśmy właściwie tylko cztery główne kroki
Pisząc ten wpis nie zauważyłem, że na j2ee.pl jest już pewnien opis DWR - dużo dłuższy więc go Wam gorąco polecam a siebie biję w pierś za duplikowanie tematu.
-
Twitter
-
Banners
Now Reading
Planned books:
- Beginning J2ME: From Novice to Professional, Third Edition (Novice to Professional) by Sing Li
- Groovy Recipes: Greasing the Wheels of Java (Pragmatic Programmers) by Scott Davis
- Java Concurrency in Practice by Brian Goetz
- Learning Python, 3rd Edition by Mark Lutz
- Beginning Python: From Novice to Professional, Second Edition (Beginning from Novice to Professional by Magnus Lie Hetland
Current books:
-
Implementing SOA : Total Architecture in Practice by Paul C. Brown
Recent books: