Mroczna historia na dobry początek

Przed monitorem jednego z terminali Biblioteki Uniwersyteckiej spędzałem kolejną dłużącą się bez końca godzinę. Na zewnątrz niebo nabierało coraz ciemniejszych barw. Poszukiwałem ciekawego tematu na nowy artykuł na j2ee.pl.

Wielogodzinna praca powodowała, że zaczynałem odczuwać nadchodzące zmęczenie. Postanowiłem podarować sobie chwilę odpoczynku od zagadnień IT. Nierozsądnie wpisałem w pasku przeglądarki tvn24.pl – strona chwilę się wczytywała. Wziąłem ostatni już łyk Red Bulla. Jak przez mgłę spoglądałem na treści atakujące moją bezbronną świadomość. W prawym dolnym rogu ujrzałem umieszczoną sondę. Zupełnie bez powodu ogarnęła mnie nagła, nieodparta ochota na to, żeby zagłosować… Lecz nagle poczułem na skórze powiew mroźnego powietrza, który w parnej sali Biblioteki wydawał się pojawić jakby znikąd. To co działo się następnie nie sposób opisać jakimikolwiek słowami. Przez chwilę zdawało mi się, że tuż za moimi plecami bezgłośnie niczym rycerz ciemności przemknął Premier Jarosław Kaczyński cenzurując swym wzrokiem oglądane przeze mnie treści. Modliłem się, żeby to wszystko nie było prawdą – nie chciałem, żeby Premier zobaczył oglądania jakich pornograficznych treści dopuszczają się studenci. Wciąż oszołomiony tym, co wydarzyło się przed chwilą postanowiłem zaczerpnąć świeżego powietrza.

(Aby przejść do części praktycznej kliknij tutaj.)

DWR?

Po krótkiej przerwie powróciłem pełen energii do dalszej pracy. Początkowo miałem kilka pomysłów, aby w końcu zdecydować się na przedstawienie frameworka Direct Web Remoting, czyli jak twierdzą jego autorzy łatwego sposobu na Ajax dla programistów Javy. Przyznam się, że dałem się im przekonać. W jakim jednak celu tworzyć kolejne wprowadzenie do tak dobrze znanego i jeszcze lepiej udokumentowanego szkieletu programistycznego. To zupełnie tak jakby dzisiaj pisać kolejną książkę o podstawowych zagadnieniach Springa, czy Hibernate‘a. Jest na sali dzisiaj ktokolwiek, kto by nie miał do czynienia z bardzo dobrymi publikacjami opisującymi te zagadnienia?… Tak właśnie myślałem!

A może jednak?

Mimo tych szargających mną wątpliwości postanowiłem dokonać krótkiej prezentacji frameworka DWR, gdyż zachowując wszystkie podobieństwa do wyżej wymienionych technologii – z DWR wydaje się być jednak nieco inaczej. Ja osobiście bliżej przyjrzeć się temu frameworkowi miałem dopiero okazję stosunkowo niedawno. Z badań opinii publicznej ;), jakie pozwoliłem sobie przeprowadzić okazało się, że nie jestem jedyną osobą, która do niedawana o DWR niewiele wiedziała – a nawet jeżeli wiedziała, to była to wiedza czysto teoretyczna.

DWR + Spring

Aktualną stabilną gałęzią jest branch 2.0.x, ale trwają intensywne prace nad wersją 3.0, która już niebawem powinna ujrzeć światło dzienne. W tym artykule będę korzystał z ostatniej dostępnej wersji stabilnej, czyli na dzień dzisiejszy – 2.0.3. Swoją uwagę skupię przede wszystkim na możliwościach integracji tego frameworka ze Springiem. Po tym nieco teoretycznym wstępie przedstawię działający przykład aplikacji webowej zwracając uwagę na szczególnie interesujące i pomocne elementy z punktu widzenia developera. Przedstawione rozwiązanie będzie miało charakter Proof of Concept, stąd też przykład którym się posłużę będzie wyjątkowo trywialny.

Cel

Gdy inwestuje się w coś swój (czy też czyjś) czas warto wiedzieć, co właściwie ma być finalnym efektem włożonej pracy. Moim celem będzie pokazanie w jaki sposób umożliwić bezpośrednie wywoływania z poziomu JavaScript metod serwisów zdefiniowanych (jako beany) w kontekście aplikacyjnym Springa.

Narzędzia, frameworki i biblioteki wykorzystane do wykonania tego ćwiczenia

• Narzędzia
  • Eclipse/JDT
  • maven2 – posłuży nam do budowania, deployowania oraz testowania aplikacji
  • maven-jetty-plugin – wtyczka do mavena pozwalająca na uruchamianie serwera aplikacji, jakim jest Jetty z poziomu mavena (bardzo przyjemne oraz efektywne narzędzie)
• Framworki i biblioteki
  • Spring Framework
  • DWR
  • jQuery

Część praktyczna

(Aby pobrać pełne źródła tworzonej aplikacji kliknij tutaj.)

Przygotowanie standardowego szablonu aplikacji webowej

Rozpocznę od utworzenia pliku pom.xml z myślą o aplikacji sieciowej korzystającej ze Spring Web MVC. Z pewnością robiłeś już takie rzeczy wiele razy.

pom.xml:
<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <modelVersion>4.0.0</modelVersion>
  <groupId>pl.jcommerce.example</groupId>
  <artifactId>dwr-example</artifactId>
  <version>0.1</version>
  <packaging>war</packaging>
  <name>j2ee.pl DWR example</name>

  <build>
    <defaultGoal>package</defaultGoal>
    <finalName>dwr-example</finalName>
    <resources>
      <resource>
        <directory>src/main/webapp/WEB-INF</directory>
      </resource>
    </resources>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <encoding>utf8</encoding>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <configuration>
          <connectors>
            <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
              <port>8080</port>
              <maxIdleTime>60000</maxIdleTime>
            </connector>
          </connectors>
          <scanIntervalSeconds>5</scanIntervalSeconds>
          <webAppConfig>
            <contextPath>/dwr-example</contextPath>
          </webAppConfig>
        </configuration>
      </plugin>
    </plugins>
  </build>

  <pluginRepositories>
    <pluginRepository>
      <id>mortbay-repo</id>
      <name>mortbay-repo</name>
      <url>http://jetty.mortbay.org/maven2/release</url>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>

  <dependencies>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.5</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>jstl</artifactId>
      <version>1.2</version>
    </dependency>

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <version>2.5.2</version>
    </dependency>

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-aop</artifactId>
      <version>2.5.2</version>
    </dependency>

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>2.5.2</version>
    </dependency>

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>2.5.2</version>
    </dependency>

  </dependencies>

</project>

Element, który może być dla Ciebie nowy i być może powinieneś na niego zwrócić uwagę, to konfiguracja wtyczki Jetty. Jeżeli nie znałeś tego narzędzia do tej pory, to z czystym sumieniem mogę Ci je polecić.

Teraz utworzę standardową dla mavena strukturę katalogów i dodam kolejne ważne z punktu widzenia projektu pliki.

web.xml:
<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
  version="2.4">

  <display-name>j2ee.pl DWR example</display-name>
  <description></description>

  <listener>
    <display-name>Spring context-loader</display-name>
    <listener-class>
      org.springframework.web.context.ContextLoaderListener
    </listener-class>
  </listener>

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      /WEB-INF/applicationContext.xml
    </param-value>
  </context-param>

  <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>
      org.springframework.web.servlet.DispatcherServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>

  <filter>
    <filter-name>CharacterEncodingFilter</filter-name>
    <filter-class>
      org.springframework.web.filter.CharacterEncodingFilter
    </filter-class>
    <init-param>
      <param-name>encoding</param-name>
      <param-value>UTF-8</param-value>
    </init-param>
  </filter>

  <filter-mapping>
    <filter-name>CharacterEncodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

</web-app>

Następnie wykonam polecenie:

mvn eclipse:eclipse -DdownloadSources=true

Po pomyślnym wykonaniu tego polecenia zostaną ściągnięte wszystkie wymagane pakiety wraz ze źródłami oraz zostaną utworzone pliki projektu Eclipse, co umożliwi nam pracę z poziomu IDE. Istnieje wiele innych sposobów integracji Eclipse z projektem maven2, ale żaden z nich nie działa do końca perfekcyjnie. W tym jednak wypadku wtyczka eclipse do mavena zdaje egzamin.

Teraz już z poziomu IDE uzupełnie konfigurację dodając pliki applicationContext.xml oraz dispatcher-servlet.xml nie zawierające na razie jednak żadnych definicji beanów.

Pierwsze uruchomienie aplikacji

Jeżeli wszystko poszło zgodnie z planem, to po wykonaniu polecenia

mvn jetty:run

powinnienem być w stanie wywołać z przeglądarki adres http://localhost:8080/dwr-example/.

Warto zauważyć, że począwszy od tej chwili po każdej zmianie dokonanej przeze mnie w plikach projektu Jetty automatycznie dokona ponownego deploymentu aplikacji. Jeżeli zmiana plików projektu nie wywoła takiego działania najprawdopodobniej należy dodać dodatkowe wpisy do elementu konfiguracyjnego wtyczki Jetty o nazwie scanTargets.

Aplikacja owszem działa, ale trudno na razie być zachwyconym jej funkcjonalnością.

Dodanie serwisu do aplikacji

Dodam teraz 3 pliki java, które będą definiowały serwis, który będę chciał w przyszłości wołać z poziomu JavaScriptu. Posłużę się prostym serwisem, który będzie posiadał zaledwie jedną metodę. Do określonego przeze mnie celu będzie to zupełnie wystarczające.

package pl.jcommerce.example.dwr.service;

import pl.jcommerce.example.dwr.model.Product;

/**
 * @author Michal Mally
 */
public interface ProductService {

  public Product getProductByCode(String code);

}

package pl.jcommerce.example.dwr.service;

import java.math.BigDecimal;
import java.util.HashSet;
import java.util.Random;
import java.util.Set;

import pl.jcommerce.example.dwr.model.Product;

/**
 * @author Michal Mally
 */
public class ProductServiceDummyImpl implements
    ProductService {

  private static final Set<Product> products;

  private static final Random random = new Random();

  static {
    products = new HashSet<Product>();
    products.add(new Product("CSS",
        "CSS: The Missing Manual", "O'Reilly Media", 3,
        BigDecimal.valueOf(2309, 2)));
    products.add(new Product("JQR", "jQuery in Action",
        "Manning Publications", 4, BigDecimal.valueOf(2639,
            2)));
    products.add(new Product("DWR",
        "Practical DWR 2 Projects", "Apress", 0, BigDecimal
            .valueOf(3101, 2)));
  }

  @Override
  public Product getProductByCode(String code) {
    for (final Product product : products) {
      if (product.getCode().equals(code.toUpperCase())) {
        return product;
      }
    }

    try {
      Thread.sleep(random.nextInt(1000));
    } catch (InterruptedException e) {
      e.printStackTrace();
    }

    return null;
  }

}

package pl.jcommerce.example.dwr.model;

import java.math.BigDecimal;

/**
 * @author Michal Mally
 */
public class Product {

  private String code;

  private String name;

  private String producer;

  private int itemsAvailable;

  private BigDecimal price;

  public Product() {
    // intentionally left blank
  }

  public Product(String code, String name, String producer,
      int itemsAvailable, BigDecimal price) {
    super();
    this.code = code;
    this.name = name;
    this.producer = producer;
    this.itemsAvailable = itemsAvailable;
    this.price = price;
  }

  // (...) getters/setters

}

Ponieważ całość będę uruchamiał lokalnie w implementacji serwisu celowo zostało dodane losowe opóźnienie, aby móc symulować realne warunki, jakie mają miejsce w Internecie. Mianowicie często zdarza się sytuacja, że odpowiedzi na wysyłane żądanie nie przychodzą w tej samej kolejności w jakiej zostały wysłane żądania.

Dodam teraz odpowiedni wpis do pliku applicationContext.xml.

  <bean id="productService" class="pl.jcommerce.example.dwr.service.ProductServiceDummyImpl">
  </bean>

A gdzie ten DWR?

Będąc w tym miejscu dodanie wsparcia dla DWR zajmie mi już zaledwie kilka minut.

Do pliku web.xml dodaje definicję servletu DWR oraz odpowiednie do niego mapowanie.

  <servlet>
    <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>

Servlet DWR skonfigurowałem w taki sposób, aby mieć możliwość debugowania.

Teraz ponownie modyfikuje plik applicationContext.xml doprowadzając go do finalnej postaci.

<?xml version="1.0" encoding="UTF-8"?>
<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"
	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 type="bean" class="pl.jcommerce.example.dwr.model.Product"/>
  </dwr:configuration>

  <bean id="productService" class="pl.jcommerce.example.dwr.service.ProductServiceDummyImpl">
    <dwr:remote javascript="ProductService">
      <dwr:include method="getProductByCode"/>
    </dwr:remote>
  </bean>

</beans>

Do zdefiniowanego już wcześniej beana productService dodaję tag dwr:remote określając, że bean, którego to dotyczy ma być dostępny z poziomu JavaScriptu pod nazwą ProductService oraz, że interesuje mnie wywoływanie metody getProductByCode().

Nie można także zapomnieć o tagu dwr:configuration, który jest wymagany niezależnie od tego, czy zawiera jakieś dodatkowe elementy. W moim przypadku określam, że klasa Product będzie transformowana z/do obiektu JavaScript przy użyciu dostępnych w niej getterów/setterów.

Pamiętać należy również o dodaniu nowej zależności do pliku pom.xml. Po tej operacji należy także ponownie wywołać mvn eclipse:eclipse -DdownloadSources=true.

    <dependency>
      <groupId>org.directwebremoting</groupId>
      <artifactId>dwr</artifactId>
      <version>2.0.2</version>
    </dependency>

Testowanie DWR przy pomocy dostarczonych wraz z frameworkiem narzędzi

Przyszedł czas na sprawdzenie, czy wszystko się powiodło. Wpisuję w przeglądarce adres http://localhost:8080/dwr-example/dwr/. Moim oczom ukazuje się lista znanych klas dla DWR:

ProductService (pl.jcommerce.example.dwr.service.ProductServiceDummyImpl)

Klikam na ProductService i uzyskuję dzięki temu dostęp do bardzo przyjemnego narzędzie pozwalającego na przetestowanie wywołania serwisu. Odnajduję metodę getProductByCode(), wpisuje jako argument jej wywołania “CSS” i klikam Execute.

W wyskakującym okienku (alert()) uzyskuje dokładne informacje o produkcie o kodzie CSS. Zatem wywołanie się powiodło :). Warto zauważyć, że także na konsoli Jetty widać wpis o wykonanym zapytaniu.

Tworzenie strony HTML korzystającej z DWR

Ostatnim już elementem tego tutoriala będzie utworzenie strony HTML umożliwiającej wyszukiwanie produktów po ich kodach bez konieczności przeładowania strony. Przykład trywialny, ale w tym wypadku wystarczający.

Ponieważ zamierzam korzystać z JavaScriptu wspomogę się biblioteką jQuery, która znacznie to ułatwia. Bibliotekę umieszczam w folderze /src/main/webapp/script/js/. Polecam bliższe zapoznanie się z tą biblioteką JS.

A teraz już źródło samej strony JSP oraz krótki opis tego, co się wewnątrz jej źródła dzieje.

<%@ page pageEncoding="UTF-8" %><?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Product search</title>

    <script type="text/javascript" src="${pageContext.request.contextPath}/script/js/jquery-1.2.3.min.js"></script>

	<script type='text/javascript' src='${pageContext.request.contextPath}/dwr/interface/ProductService.js'></script>
	<script type='text/javascript' src='${pageContext.request.contextPath}/dwr/engine.js'></script>

    <script type="text/javascript">
    	// <![CDATA[
    	var lastRequestId = 0;

    	function onProductReceived(product) {
    		if (product != null) {
    			$("#productDescription").show();
    			$("#invalidCode").hide();

    			$("#productCode").html(product.code);
    			$("#productName").html(product.name);
    			$("#productProducer").html(product.producer);
    			$("#productItemsAvailable").html(product.itemsAvailable);
    			$("#productPrice").html(product.price);

    			return;
    		}

    		$("#invalidCode").show();
    		$("#productDescription").hide();
    	}

    	$(document).ready(
    		function(){
    			$("#productDescription").hide();
    			$("#invalidCode").hide();
    			$("#productCodeInput").keyup(
    				function() {
    					var requestId = ++lastRequestId;

    					ProductService.getProductByCode($(this).val(), {
	    						callback: function(product) {
	    							if (requestId != lastRequestId) {
	    								return;
	    							} 

			    					onProductReceived(product);
			    				}
		    				}
		    			)
    				}
    			);
    		}
    	);
    	// ]]>
    </script>

  </head>
  <body>
	<p>Enter product code <input id="productCodeInput" type="text"/></p>
	<div id="productDescription">
		<p>Product code: <span id="productCode"></span></p>
		<p>Product name: <span id="productName"></span></p>
		<p>Producer: <span id="productProducer"></span></p>
		<p>Items available: <span id="productItemsAvailable"></span></p>
		<p>Price: <span id="productPrice"></span></p>
	</div>
	<div id="invalidCode">
		<p><strong>You have chosen invalid code! Please choose another one.</strong></p>
	</div>
  </body>
</html>

W bloku head załączam źródło biblioteki jQuery oraz kod wygenerowany przez DWR będący naszym punktem dostępu do serwisu ProductService. Trochę niżej definiujemy funkcję onProductChange, która będzie wywoływana w momencie uzyskania odpowiedzi z serwisu. Jej zadaniem będzie podmiana części informacji na stronie zgodnie z aktualnie wprowadzonym przez użytkownika kodem produktu.

Zapytanie do serwisu wysyłam każdorazowo po tym jak zajdzie zdarzenie zwolnienia przez użytkownika klawisza. W prawdziwych aplikacjach całkowicie odradzam tą technikę, jednak dla celów tego artykułu jest ona wystarczająca.

Ponieważ użytkownik może z dosyć dużą częstotliwością powodować wysłanie żądań do serwisu musimy się zabezpieczyć przed sytuacją w której nieaktualna odpowiedź nadpisze aktualną wartość. Do tego posłuży nam zmienna requestId. Przy każdorazowym odebraniu odpowiedzi z serwisu będziemy sprawdzali, czy nie zostało przypadkiem wysłane nowsze żądanie. W takim przypadku starsza odpowiedź zostanie przeze mnie zignorowana.

Gdybym nie potrzebował stosować wyżej opisanej techniki wywołanie serwisu mogłoby wyglądać jak poniżej.

ProductService.getProductByCode($(this).val(), onProductChanged);

Aby całość dostępna była poprzez adres http://localhost:8080/dwr-example/product/search.html uzupełnię jeszcze plik dispatcher-servlet.xml.

<?xml version="1.0" encoding="UTF-8"?>
<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="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  	  <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
  	  <property name="prefix" value="/WEB-INF/jsp/" />
  	  <property name="suffix" value=".jsp" />
  	</bean>

  	<bean name="/product/search.html" class="org.springframework.web.servlet.mvc.UrlFilenameViewController" />

</beans>

Podsumowanie

Nieprzekonany?

DWR jest dojrzałym frameworkiem. W tym artykule główną uwagę skupiłem na jego prostocie wykorzystywania w kontekście aplikacji webowej budowanej na Springu. Pokazałem zaledwie od czego nasza zabawa z DWR może się rozpocząć. Dla projektantów i programistów bardzo ważnym aspektem natomiast jest elastyczność rozwiązań z których się korzysta oraz możliwość łatwego ich dostosowania do własnych potrzeb. Przeglądając oficjalną dokumentację szybko można się zorientować, że DWR w tej dziedzinie stara się spełniać stawiane mu oczekiwania.

Nie poruszyłem w tym artykule żadnego zaawansowanego aspektu DWR, ale wierzę, że jeżeli zdecydujesz się na korzystanie z tego frameworka, to dzięki dobrze napisanej dokumentacji nie będziesz miał problemu z jego dostosowaniem.

Odnośniki

1. DWR
2. jQuery
3. Spring Framework
4. Jetty
5. Maven

Budowa GWT

Na początek przyjrzymy się, co tak naprawdę kryje się nazwą GWT. GWT składa się z czterech podstawowych komponentów.

Pierwszy z nich, kompilator Java-to-JavaScript, tłumaczy kod źródłowy na JavaScript i HTML. Oczywiście, aby kod mógł zostać poprawnie przetłumaczony, musi spełniać szereg ograniczeń. Przede wszystkim należy pamiętać, że GWT w obecnej wersji (1.4) jest zgodny z Javą 1.4.2, więc użycie jakichkolwiek rozszerzeń Javy 1.5 skończy się błędem kompilacji. Poza tym należy zapomnieć o takich przyjemnościach jak wielowątkowość czy refleksja.

Drugi komponent to dedykowana przeglądarka WWW. Umożliwia ona uruchomienie aplikacji bez translacji do JavaScriptu, w tzw. Hosted Mode. Szczegóły – za chwilę.

Trzeci komponent to biblioteka emulująca podstawowe klasy biblioteki standardowej Javy w JavaScripcie. Zawiera ona implementację większości klas z java.lang, oraz część java.util.

Czwarty komponent, czyli biblioteka Web UI, służy do tworzenia interfejsu użytkownika który zostanie następnie przetłumaczony na stronę WWW.

Hosted Mode vs. Web Mode

GWT oferuje nam dwa tryby uruchomienia stworzonej aplikacji. Pierwszy z nich, tzw. Hosted Mode, wykorzystując wspomnianą już dedykowaną przeglądarkę WWW uruchamia aplikację bezpośrednio w wirtualnej maszynie Javy, bez tłumaczenia kodu do JavaScriptu. To pozwala programiście korzystać z takich dobrodziejstw Javy, jak chociażby wygodne debugowanie kodu. Z tego względu Hosted Mode jest używany w trakcie procesu tworzenia aplikacji.

Z kolei Web Mode polega na skompilowaniu kodu do HTMLa i JavaScriptu i uruchomieniu tak przygotowanej aplikacji w dowolnej przeglądarce WWW. Ten tryb używany jest przy wdrażaniu gotowej aplikacji.

GWT w praktyce

Po krótkim wprowadzeniu czas przejść do konkretów, czyli przykładowej aplikacji. Będzie to prosty kalendarz zamieszczony na stronie WWW.
Aby użyć GWT wystarczy pobrać wersję odpowiednią dla używanego systemu ze strony http://code.google.com/webtoolkit i rozpakować ją do dowolnego katalogu. Dla wygody warto dopisać go do zmiennej środowiskowej PATH.

Do stworzenia projektu skorzystamy z dwóch skryptów dostarczonych wraz z GWT: projectCreator oraz applicationCreator. Pierwszy z nich posłuży do stworzenia plików projektu Eclipse’a, drugi do wygenerowania podstawowych plików aplikacji.

C:\\projects\\gwtcalendar>projectCreator.cmd -eclipse gwtcalendar
Created directory C:\\projects\\gwtcalendar\\src
Created directory C:\\projects\\gwtcalendar\\test
Created file C:\\projects\\gwtcalendar\\.project
Created file C:\\projects\\gwtcalendar\\.classpath

C:\\projects\\gwtcalendar>applicationCreator.cmd -eclipse gwtcalendar pl.jcommerce.example.gwtcalendar.client.Calendar
Created directory C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar
Created directory C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar\\client
Created directory C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar\\public
Created file C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar\\Calendar.gwt.xml
Created file C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar\\public\\Calendar.html
Created file C:\\projects\\gwtcalendar\\src\\pl\\jcommerce\\example\\gwtcalendar\\client\\Calendar.java
Created file C:\\projects\\gwtcalendar\\Calendar.launch
Created file C:\\projects\\gwtcalendar\\Calendar-shell.cmd
Created file C:\\projects\\gwtcalendar\\Calendar-compile.cmd

Skrypt applicationCreator tworzy strukturę pakietów zgodną z zaleceniami GWT:
.../gwtcalendar – główny pakiet zawierający wszystkie pliki projektu. Bezpośrednio w tym pakiecie tworzony jest plik konfiguracyjny XML.
.../gwtcalendar/client – pakiet zawierający pliki źródłowe warstwy klienta. To właśnie te pliki będą później tłumaczone na JavaScript.
.../gwtcalendar/public – w tym pakiecie zawarte są statyczne zasoby takie jak gotowe pliki html, css czy grafika.
W typowych aplikacjach występuje dodatkowo pakiet .../gwtcalendar/server, zawierający źródła warstwy serwerowej. Ta część kodu nie podlega kompilacji do JavaScriptu, więc nie obowiązują tu żadne ograniczenia nałożone przez GWT. W naszej przykładowej aplikacji zajmiemy się tylko warstwą klienta, więc ten pakiet jest zbędny.

Dodatkowo stworzone zostały trzy pliki w katalogu głównym projektu:
Calendar.launch – plik projektu Eclipse’a pozwalający uruchomić projekt w trybie debug
Calendar-shell.cmd – skrypt uruchamiający aplikację w Hosted Mode
Calendar-compile.cmd – skrypt kompilujący aplikację do postaci HTMLa i JavaScriptu w celu uruchomienia jej w trybie Web Mode

Po wykonaniu powyższych skryptów importujemy projekt do Eclipse’a i przystępujemy do dokładniejszych oględzin plików w pakiecie .../gwtcalendar.
Najpierw przyjrzyjmy się plikowi konfiguracyjnemu modułu Calendar.gwt.xml:

<module>

   <!-- Inherit the core Web Toolkit stuff.                  -->
   <inherits name='com.google.gwt.user.User'/>

   <!-- Specify the app entry point class.                   -->
   <entry-point class='pl.jcommerce.example.gwtcalendar.client.Calendar'/>

</module>

Jak widać nie jest on zbyt skomplikowany. Pierwszy element, inherits, wskazuje na dziedziczenie ze standardowego modułu interfejsu użytkownika GWT. Drugi element, entry-point, wskazuje na główną klasę modułu. W momencie wczytania strony WWW, wykonana zostanie metoda onModuleLoad() wskazanej klasy. Główna klasa modułu musi implementować interfejs com.google.gwt.core.client.EntryPoint.

Teraz przejdźmy do naszej statycznej strony WWW, czyli pliku Calendar.html. Wygenerowana, przykładowa zawartość pokazuje, jak można użyć modułu GWT jako część istniejącej strony WWW. W naszym przypadku w zupełności wystarczy mocno okrojona wersja:

<html>
   <head>

      <title>Calendar</title>

   </head>
   <body>

      <script language='javascript' src='pl.jcommerce.example.gwtcalendar.Calendar.nocache.js'></script>

      <!-- OPTIONAL: include this if you want history support -->
      <iframe src="javascript:''" id="__gwt_historyFrame" style="width:0;height:0;border:0"></iframe>

   </body>
</html>

Nie ma tu za wiele do wyjaśniania. W elemencie script podajemy nazwę modułu z końcówką .nocache.js. Z kolei umieszczenie elementu iframe pozwala na wykorzystanie wsparcia historii przeglądarki oferowanego przez GWT. W naszej przykładowej aplikacji nie ma to żadnego zastosowania, ale warto pamiętać o tym udogodnieniu.

Na koniec trzeci, najbardziej interesujący plik, czyli Calendar.java. Podobnie jak w przypadku Calendar.html, wygenerowana treść metody onModuleLoad() jest tylko przykładowa i od razu możemy się jej pozbyć.

Przyjrzyjmy się teraz budowie interfejsu użytkownika za pomocą GWT. Podstawową klasą interfejsu jest com.google.gwt.user.client.ui.Widget. Z Widget dziedziczą wszystkie elementy UI takie jak przyciski, pola tekstowe, tabele i wiele innych. Szczególnym elementem jest com.google.gwt.user.client.ui.Panel, abstrakcyjna klasa bazowa dla wszystkich kontenerów. GWT, w odróżnieniu od np. Swinga, nie używa odrębnych klas typu LayoutManager. Układem komponentów zarządzają bezpośrednio klasy dziedziczące z Panel, takie jak HorizontalPanel, VerticalPanel, FlowPanel czy DockPanel. Aby umieścić jakiekolwiek komponenty na stronie musimy uzyskać dostęp do głównego panelu. Służy do tego metoda statyczna RootPanel.get().

Interfejs naszego kalendarza będzie się składał z nagłówka zawierającego przyciski do zmiany wyświetlanego miesiąca, paska z etykietami oznaczającymi kolejne dni tygodnia oraz panelu przedstawiającego dni miesiąca. Na początek kilka zmiennych i stałych wykorzystywanych w naszej klasie, oraz metoda onModuleLoad():

private int currYear;private int currMonth;
private VerticalPanel mainPanel;
private Label monthLabel;
private Widget monthPanel;private static final int DAY = 1000 * 3600 * 24;
private static final int WEEK = DAY * 7;
private static final String[] dayNames = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" };

/**
 * This is the entry point method.
 */
public void onModuleLoad() {
   Date date = new Date();
   currYear = date.getYear();
   currMonth = date.getMonth();
   initUI();
}

Zmienne mainPanel, monthLabel oraz monthPanel będą przechowywać komponenty, do których potrzebny będzie dostęp w metodach odpowiedzialnych za „dynamikę” naszej aplikacji. Reszta kodu nie wymaga chyba komentarza. Przyjrzyjmy się wobec tego kolejnej metodzie tworzącej interfejs:

private void initUI() {
   mainPanel = new VerticalPanel();
   mainPanel.setWidth("250px");
   mainPanel.setSpacing(3);
   mainPanel.add(createHeaderPanel());
   mainPanel.add(createDayNamesPanel());
   mainPanel.add(monthPanel = createMonthPanel());
   RootPanel.get().add(mainPanel);
}

W tej metodzie tworzymy główny panel, ustawiamy jego parametry i dodajemy podstawowe elementy. Na koniec ustawiamy go jako jedyny element RootPanela. Warto zwrócić uwagę na wywołanie metody setWidth(), która przyjmuje parametr typu String, a nie int. Metoda ta przyjmuje wszystkie poprawne wartości CSS, a więc poprawne będzie zarówno „250px”, jak i „5cm” czy „15%”.

Następne dwie metody tworzą nagłówek naszego kalendarza:

private Widget createHeaderPanel() {
   HorizontalPanel headerPanel = new HorizontalPanel();
   headerPanel.setWidth("100%");
   headerPanel.setSpacing(3);
   Button prevButton = new Button("<<");
   prevButton.setWidth("100%");
   headerPanel.add(prevButton);
   headerPanel.setCellWidth(prevButton, "20%");
   monthLabel = new Label((currYear + 1900) + "-" + (currMonth + 1));
   headerPanel.add(monthLabel);
   headerPanel.setCellHorizontalAlignment(monthLabel,
         HasHorizontalAlignment.ALIGN_CENTER);
   Button nextButton = new Button(">>");
   nextButton.setWidth("100%");
   headerPanel.add(nextButton);
   headerPanel.setCellWidth(nextButton, "20%");
   return headerPanel;
}

private Widget createDayNamesPanel() {
   HorizontalPanel dayNamesPanel = new HorizontalPanel();
   dayNamesPanel.setWidth("100%");
   dayNamesPanel.setSpacing(3);
   Label lab;
   for (int i = 0; i < dayNames.length; i++) {
      lab = new Label(dayNames[i]);
      lab.setWidth("100%");
      dayNamesPanel.add(lab);
      dayNamesPanel.setCellWidth(lab, "14%");
      dayNamesPanel.setCellHorizontalAlignment(lab, HasHorizontalAlignment.ALIGN_CENTER);
   }
   return dayNamesPanel;
}

Jak widać uzyskanie żądanego układu komponentów nie powinno sprawić problemów programiście posiadającemu chociaż podstawowe doświadczenia z takimi bibliotekami GUI jak Swing czy SWT. Bardzo pomocne są metody setCellWidth() czy setCellHorizontalAlignment(), pozwalające ustawić rozmiar i ułożenie osobno dla każdego elementu.
Kolejne dwie metody tworzą panel przedstawiający dni miesiąca:

private Widget createMonthPanel() {
   VerticalPanel monthPanel = new VerticalPanel();
   monthPanel.setWidth("100%");
   monthPanel.setSpacing(3);
   Date firstDay = new Date(currYear, currMonth, 1);
   Date currDay = new Date(firstDay.getTime() - firstDay.getDay() * DAY);
   monthPanel.add(getWeekPanel(currDay));
   while ((currDay = new Date(currDay.getTime() + WEEK)).getMonth() == firstDay.getMonth()) {
      monthPanel.add(getWeekPanel(currDay));
   }
   return monthPanel;
}

private Widget getWeekPanel(Date date) {
   HorizontalPanel weekPanel = new HorizontalPanel();
   weekPanel.setWidth("100%");
   weekPanel.setSpacing(3);
   Date firstDay = new Date(date.getTime() - date.getDay() * DAY);
   for (int i = 0; i < 7; i++) {
      Date btnDate = new Date(firstDay.getTime() + i * DAY);
      Button btn = new Button(String.valueOf(btnDate.getDate()));
      if (btnDate.getMonth() != currMonth) {
         btn.setEnabled(false);
      }
      btn.setWidth("100%");
      weekPanel.add(btn);
      weekPanel.setCellWidth(btn, "14%");
   }
   return weekPanel;
}

W powyższych metodach nie ma w zasadzie niczego nowego, poza nieco karkołomnym żonglowaniem datami. Jeśli zastanawiasz się, dlaczego konsekwentnie używamy oznaczonych jako deprecated metod klasy Date, zamiast użyć znacznie wygodniejszej klasy Calendar, odpowiedź brzmi: klasa Calendar nie istnieje. A właściwie: klasa Calendar należy do tej znaczącej części pakietu java.util, której GWT nie implementuje. Pozostaje więc zacisnąć zęby i radzić sobie z tym, co mamy.

Ale wróćmy do naszej aplikacji. Mamy już wszystko co potrzeba do stworzenia interfejsu. Efekt możemy obejrzeć uruchamiając nasz projekt (bezpośrednio za pomocą Eclipse’a lub za pomocą skryptu Calendar-shell.cmd).

Teraz, gdy mamy stworzony interfejs, czas tchnąć życie w naszą stronę WWW. Do obsługi zdarzeń GWT wykorzystuje wzorzec Listener, dobrze znany np. ze Swinga. Na początek dodajmy interfejs com.google.gwt.user.client.ui.ClickListener do deklaracji naszej klasy Calendar:

public class Calendar implements EntryPoint, ClickListener {
   ...
}

Następnie dopiszmy parę metod odpowiedzialnych za obsługę zdarzeń:

public void onClick(Widget sender) {
   String text = ((Button) sender).getText();
   if ("<<".equals(text)) {
      prevMonth();
   } else if (">>".equals(text)) {
      nextMonth();
   } else {
      Window.alert(text + "-" + (currMonth + 1) + "-" + (currYear + 1900));
   }
}

private void prevMonth() {
   if (currMonth > 0) {
      currMonth--;
   } else {
      currYear--;
      currMonth = 11;
   }
   refreshMonthPanel();
}

private void nextMonth() {
   if (currMonth < 11) {
      currMonth++;
   } else {
      currYear++;
      currMonth = 0;
   }
   refreshMonthPanel();
}

private void refreshMonthPanel() {
   monthLabel.setText((currYear + 1900) + "-" + (currMonth + 1));
   mainPanel.remove(monthPanel);
   mainPanel.add(monthPanel = createMonthPanel());
}

Na koniec musimy podpiąć obsługę kliknięć do stworzonych przycisków:

private Widget createHeaderPanel() {
   ...
   Button prevButton = new Button("<<");
   prevButton.setWidth("100%");
   prevButton.addClickListener(this);
   ...
   Button nextButton = new Button(">>");
   nextButton.setWidth("100%");
   nextButton.addClickListener(this);
   ...
}

private Widget getWeekPanel(Date date) {
   ...
   for (int i = 0; i < 7; i++) {
      ...
      Button btn = new Button(String.valueOf(btnDate.getDate()));
      btn.addClickListener(this);
   ...
}

W ten sposób dotarliśmy do końca, nasza przykładowa aplikacja jest gotowa. Wystarczy uruchomić skrypt Calendar-compile.cmd, a w katalogu WWW pojawi się nasza aplikacja przetłumaczona na HTML i JavaScript, gotowa do uruchomienia w dowolnej przeglądarce WWW lub umieszczenia na serwerze.

Podsumowanie

Oczywiście zaprezentowana aplikacja pokazuje tylko skromny wycinek możliwości GWT. Nie wspomnieliśmy o prostej komunikacji z serwerem za pomocą RPC, ułatwionej internacjonalizacji czy bezpośrednich wstawkach JavaScript za pomocą JavaScript Native Interface (JSNI). Jednak już tak prosty przykład pokazuje jak łatwo można tworzyć dynamiczne strony WWW używając jedynie Javy. Jeśli dodatkowo wierzyć zapewnieniom autorów o kompatybilności stworzonego kodu ze wszystkimi wiodącymi przeglądarkami WWW oraz o wydajności porównywalnej z ręcznie tworzonymi stronami AJAX, wówczas warto bliżej zainteresować się frameworkiem Google Web Toolkit.

Prototype

Sama biblioteka to jeden plik, który możemy szybko dodać do projektu. Wystarczy zaimportować jeszcze jeden plik ze skryptami JavaScript i gotowe.

Rozszerzanie modelu DOM

A teraz kilka słów na temat ciekawego pomysłu twórcy opisywanej biblioteki, czyli rozszerzania modelu DOM. Na czym ono polega i co nam właściwie daje? Otóż, chodzi o to byśmy przy odnoszeniu się do elementów strony www wykorzystywali funkcję $(). Funkcja ta przyjmuje jako argument identyfikator danego elementu i zwraca referencję do obiektu ‘Element’, który opakowuje standardowy obiekt zwracany przez document.getElementById(). Owo opakowanie polega na rozszerzeniu zbioru metod, jakie możemy wywoływać o te zawarte w Element.Methods i Element.Methods.Simulated. Od tej pory mamy dostęp do dodatkowych funkcji, które możemy wywołać na pobranym elemencie.

Zacznijmy może od prostego przykładu, w którym zobaczymy jak działa owo rozszerzanie modelu DOM przez Prototype.

<head>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"/>
 <script src="ścieżka/do/prototype.js" type="text/javascript"></script>
 <script type="text/javascript" >
  function powitaj() {
   alert( $('welcomeSection').innerHTML );
  }
  function ukryj(obj) {
   $(obj).hide();
  }
  function pokaz(obj) {
   $(obj).show();
  }
 </script>
</head>
<body>
 <span id="secretSection">Tę sekcję możemy ukryć</span>
 <button onclick="ukryj('secretSection')">Ukryj</button>
 <button onclick="pokaz('secretSection')">Pokaż</button>
 <div id="welcomeSection">Witaj</div>
 <button onclick="powitaj()">Powitaj</button>
</body>
</html>

Powyższy przykład pokazuje w jak prosty sposób możemy uzyskać dostęp do szerokiej gammy dodatkowych funkcji oferowanych przez Prototype. Wykorzystując funkcję $() pobieramy referencję do elementów o identyfikatorach ‘welcomeSection’ i ’secretSection’ i wywołujemy na nich funkcje z biblioteki Prototype. W przypadku funkcji powitaj() odnosimy się jedynie do własności innerHTML. Nazwy zaprezentowanych funkcji mówią same za siebie. Funkcje hide() i show() kolejno ukrywają i pokazują sekcję ’secretSection’. Owo ukrywanie i pokazywanie polega na zmianie stylu pobranego elementu. My jednak nie musimy tego wiedzieć. Po prostu wywołujemy funkcje na danym elemencie i uzyskujemy spodziewany efekt. By osiągnąć to samo bez wykorzystania Prototype musielibyśmy napisać taki oto fragment:

document.getElementById('secretSection').style.display = 'none';

Wykorzystując prezentowaną bibliotekę wystarczy, że napiszemy:

$('secretSection').hide();

Proste. Genialne ;)

Gdy przy pomocy funkcji $() pobierzemy jeden z elementów formularza (input, textarea, select) to wówczas mamy do dyspozycji nieco więcej funkcji, które możemy wywołać. Dzieje się tak dlatego gdyż zwracany obiekt jest dodatkowo rozszerzany o metody z Form.Element.Methods. Natomiast jeśli pobierzemy formularz (form) to rozszerzenie nastąpi o metody z Form.Methods. Są to funkcje umożliwiające np. deaktywowanie pól formularza, czy też czyszczenie ich zawartości. Jednak gdy spróbujemy je wywołać na elemencie nie będącym formularzem, bądź jednym z jego pól to wówczas zostaniemy poinformowani o błędzie.

<script type="text/javascript" >
 function deaktywuj(id) {
  $(id).disable();
 }
 function aktywuj(id) {
  $(id).enable();
 }
</script>
<div id="opis"><h2>Formularz danych osobowych</h2></div>
<form action="ex2.html" id="form1">
 <label>Imię: </label><input type="text" id="imie"/><br>
 <label>Hobby: </label><textarea rows="5" cols="20" id="hobby"></textarea><br>
 <input type="submit" value="Zapisz" id="zapisz"/>
</form>

<button onclick="deaktywuj('imie')">Deaktywuj</button>
<button onclick="aktywuj('imie')">Aktywuj</button>
<button onclick="deaktywuj('form1')">Deaktywuj formularz</button>
<button onclick="deaktywuj('opis')">Test błędu</button>

Przykład przedstawia prosty formularz zawierający dwa pola do wprowadzenia danych oraz przycisk powodujący wysłanie tychże danych do serwera. Ponadto na stronie znajdują się przyciski modyfikujące formularz. Dwa pierwsze, ‘Deaktywuj’ i ‘Aktywuj’ modyfikują stan pola ‘imie’ wykorzystując funkcje ‘aktywuj’ oraz ‘deaktywuj’. Każda z nich otrzymuje identyfikator elementu, który pozwoli na jego “wydobycie” przy pomocy funkcji $(). Pobrany obiekt opakowany jest w metody z Element.Methods, Element.Methods.Simulated oraz Form.Element.Methods. Metoda disable/enable, którą następnie wywołujemy jest funkcją zdefiniowaną w Form.Element.Methods. Nieco inaczej mechanizm rozszerzania modelu DOM zachowuje sie gdy przekazujemy identyfikator formularza ‘form1′. Funkcja $() zwraca obiekt posiadający metody z Element.Methods, Element.Methods.Simulated oraz Form.Methods. Teraz wywołujemy metodę disable/enable zdefiniowaną w Form.Methods, która modyfikuje wszystkie elementy formularza, a nie jak poprzednia tylko jeden.

Funcja $() ma inne, ciekawe właściwości o czym zaraz napiszę. Po pierwsze może ona przyjmować jako argument również obiekt zwrócony przez document.getElementById() i podobnie jak wcześniej zwróci nam obiekt typu ‘Element’. Jeśli natomiast podamy w wywołaniu funkcji kilka identyfikatorów to jako rezultat jej działania otrzymamy tablicę obiektów ‘Element’. Ciekawym pomysłem jest też możliwość potokowego wywoływania metod na obiektach. Jako, że spora liczba funkcji zwraca referencję do obiektu, który modyfikuje nic nie stoi na przeszkodzie by od razu wywołać na nim kolejną metodę. Oto prosty przykład:

<div id="topSecret" style="display:none;">Ten tekst jest niewidoczny.</div>
<script type="text/javascript">
 $('topSecret').update('Tajne dane juz nie są tajne.').show();
</script>

Pomimo tego, że po zastosowaniu funkcji $() mamy do naszej dyspozycji całkiem pokaźny zbiór funkcji ułatwiający modyfikację elementów, czy też prostsze poruszanie się po drzewie DOM Prototype daje nam możliwość rozszerzenia tegoż zbioru o nasze własne metody. Posługując się funkcją Element.addMethods() możemy dołączyć nasze, opracowane w pocie czoła, metody. Musimy jedynie pamiętać by jako pierwszy argument przyjmowały obiekt, na którym będą operować. Jeśli dodatkowo będziemy zwracać jego referencję to tym samym zapewnimy możliwość potokowego wywoływania naszych funkcji. Oto przykład:

<script type="text/javascript">
 var MyMethods = {
  showValue: function(element){
   alert( $(element).innerHTML );
   return element;
  },
  setDefaultValue: function(element, value){
   return $(element).update(value);
  }
 }

 Element.addMethods(MyMethods);

 function testNaszychMetod() {
  $('newsContent').setDefaultValue('Nowa treść').showValue();
 }
</script>

AJAX

W tej części artykułu zobaczymy w jaki sposób Prototype może nam ułatwić stosowanie technologii Ajax w naszym projekcie.

Zakładam, że osoba czytająca ten artykuł ma zainstalowanego mavena ponieważ wykorzystamy to narzędzie do budowy aplikacji webowej. Tak więc na początek stwórzmy katalog w wybranej przez siebie lokalizacji i wywołajmy w nim komendę

mvn archetype:create
 -DgroupId=pl.j2ee.prototypejs
 -DartifactId=prototypejs
 -DarchetypeArtifactId=maven-archetype-webapp

Powinna się ona zakończyć komunikatem BUILD SUCCESSFUL, a wynikiem jej działania będzie katalog o nazwie prototypejs zawierający strukturę aplikacji webowej odpowiednią dla mavena. Gdy będziemy wywoływać polecenie mvn install maven zbuduje nam wersję aplikacji gotową do uruchomienia na serwerze. Do uruchomienia prezentowanych przykładów wykorzystamy serwer tomcat w wersji 5.5. Wróćmy może do naszego projektu. Poleceniem archetype:create utworzyliśmy szkielet aplikacji, który teraz powinniśmy nieco zmodyfikować. Na początek dodamy kilka wpisów do pom.xml dotyczących zależności, zewnętrznego repozytorium oraz buildu. Nasz plik pom.xml powinien wyglądać tak:

<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>pl.j2ee.prototype</groupId>
 <artifactId>prototypejs</artifactId>
 <packaging>war</packaging>
 <version>1.0-SNAPSHOT</version>
 <name>prototypejs Maven Webapp</name>
 <url>http://maven.apache.org</url>
 <dependencies>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>3.8.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>tomcat</groupId>
   <artifactId>servlet-api</artifactId>
   <version>5.5.15</version>
  </dependency>
 </dependencies>
 <build>
  <finalName>prototypejs</finalName>
  <plugins>
   <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
     <source>1.5</source>
     <target>1.5</target>
    </configuration>
   </plugin>
  </plugins>
 </build>
 <repositories>
  <repository>
   <name>ibiblio</name>
   <id>ibiblio</id>
   <url>http://www.ibiblio.org/maven/</url>
  </repository>
 </repositories>
</project>

Jako że nasza aplikacja ma prezentować wykorzystanie technologii Ajax to musimy przygotować serwlet, który będzie generował odpowiedź dla żądań ajaxowych.
W katalogu prototypejs\src\main\ utwórzymy dodatkowy katalog o nazwie java a w nim w pakiecie pl.j2ee.prototypejs.servlet klasę serwletu DataServlet. Docelowo będzie on obsługiwał żądania typu get i post.

package pl.j2ee.prototypejs.servlet;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import java.io.PrintWriter;
import java.io.IOException;
import java.util.Date;

public class DataServlet extends HttpServlet {
 public void doGet(HttpServletRequest req,
  HttpServletResponse res)
  throws ServletException, IOException {
  PrintWriter out = res.getWriter();

  out.println("Wiadomosc pobrana o " + new Date());

  String osoba = (String) req.getParameter("osoba");
  if (osoba != null)
   out.println( " Osoba: " + osoba);

  out.close();
 }

 public void doPost(HttpServletRequest req,
  HttpServletResponse res)
  throws ServletException, IOException {
   PrintWriter out = res.getWriter();
   String text = "Tekst o 7 krasnoludkach i innych takich.";

   out.println("Dane pobrane o " + new Date());
   for (int i = 0; i < 10; i++)
    out.println(text);

   out.close();
 }
}

Metoda doGet zwraca jako odpowiedź tekst zawierający datę jej wygenerowania. Jeśli w żądaniu ajaxowym podamy parametr o nazwie osoba to zostanie on również dodany do odpowiedzi.
Dobrze. Mamy już potrzebny serwlet wiec teraz dodamy o nim wpis do deskryptora serwera czyli pliku web.xml.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

 <display-name>J2ee.pl - Prototype</display-name>

 <servlet>
  <servlet-name>dataServlet</servlet-name>
  <servlet-class>pl.j2ee.prototypejs.servlet.DataServlet</servlet-class>
 </servlet>

 <servlet-mapping>
  <servlet-name>dataServlet</servlet-name>
  <url-pattern>/data</url-pattern>
 </servlet-mapping>

 <welcome-file-list>
  <welcome-file>index.html</welcome-file>
 </welcome-file-list>
</web-app>

Jak widzimy serwlet DataServlet będzie obsługiwał żądania, które zostaną dopasowane do wzorca /data.
I jeszcze strona html. Zawiera ona kilka sekcji, w których będziemy umieszczać dane przychodzące z serwera w kilku następnych przykładach oraz funkcję javascrpit wysyłającą ajaxowe żądanie.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"/>
 <script src="js/prototype.js" type="text/javascript"></script>
 <style type="text/css">
  .section {
   margin: 5px 5px 5px 5px;
   padding: 2px 2px 2px 2px;
   width: 500px;
  }
  .data {
   background-color: #60A7F2;
   border: 2px solid #388EF2;
  }
  .errors {
   background-color: #FF9966;
   border: 2px solid #ED3D16;
  }
 </style>
</head>
<body>
 <script type="text/javascript">
  function testAjax() {
   new Ajax.Request('/prototypejs/data',
    {
     method:'get',
     onSuccess: function(transport) {
      $('news').innerHTML = transport.responseText || "brak danych";
     },
     onFailure: function() {
      alert('Wystąpił błąd podczas pobierania danych...')
     }
    });
  }
 </script>
 <button onclick="testAjax()">Pobież dane</button>
 <div class="section data">Dane pobrane z serwera: <span id="news"></span></div>
 <div id="errors" class="section errors"></div>
 <div id="newsContent" class="section data">Dane pobrane z serwera:</div>
 <div class="section data">Dane w tej sekcji będą uaktualniane okresowo:
  <span id="dynamicContent"></span>
 </div>
</body>
</html>

W Prototype funkcjonalność związana z technologią Ajax została zawarta w obiekcie Ajax oraz kilku funkcjach serializujacych dane. Żądania ajaxowe wysyłamy w bardzo prosty sposób. Wystarczy utworzyć obiekt Ajax.Request, wskazać url, do którego ma się odnieść oraz podać kilka parametrów związanych z żądaniem i jego obsługą. Konstruktor obiektu Ajax.Request przyjmuje dwa parametry. Pierwszym z nich jest url, a drugim hashmapa z parametrami. W naszym przykładzie podajemy trzy parametry: typ żądania oraz funkcje obsługującą dane w przypadku poprawnej bądź niepoprawnej obsługi naszego żądania. Żądania ajaxowe są z reguły asynchroniczne, stąd metody, które przekazujemy do ich obsługi są traktowane jako funkcje callback. Oznacza to iż są one wywoływane gdy otrzymamy odpowiedni status obsługi naszego żądania ajaxowego. Tutaj znajdziemy spis parametrów, które możemy podać w żądaniu wraz z ich domyślnymi wartościami.
Dla osób, którym powyższy zapis wydaje się nieco nieprzejrzysty mam dobrą wiadomość. Otóż możemy przepisać powyższy kod javascript do nieco ładniejszej postaci. Drugi argument możemy zapisać w notacji JSON. Teraz nasza funkcja wygląda nieco przejrzyściej.

<script type="text/javascript">
 function putText(transport) {
  $('news').innerHTML = transport.responseText || "brak danych";
 }
 function showErrorMsg() {
  alert('Wystąpił błąd podczas pobierania danych...');
 }

 function testAjax() {
  var url      = "/prototypejs/data";
  var params = new Object();

  params.method = "get";
  params.parameters = "osoba=Leszek Peszek";
  params.onComplete = putText;
  params.onFailure = showErrorMsg;

  new Ajax.Request(url, params);
 }
</script>

Ajax często wykorzystywany jest w ten sposób, że pobiera część strony www z serwera i bez modyfikacji wstawia ją do odpowiedniej sekcji strony. Prototype wychodzi na przeciw tym praktykom udostępniając obiekt Ajax.Updater. Działa on na podobnej zasadzie co Ajax.Request, tyle że umożliwia stosowanie łatwiejszego zapisu. W konstruktorze obiektu podajemy tym razem trzy argumenty. Są to: identyfikator sekcji, do której wstawiona zostanie pobrana z serwera treść, url oraz parametry żądania. Oto malutki przykład.

<script type="text/javascript">
 function testAjax() {
  new Ajax.Updater('newsContent', '/prototypejs/data',
   { method: 'post'}
  );
 }
</script>

Nie musimy podawać żadnych funkcji obsługujących to żądanie. Jeśli otrzymamy status żądania świadczący o udanym pobraniu danych z serwera to Prototype sam wstawi pobraną treść do wskazanej sekcji. Bardzo zgrabnie obsługiwany jest przypadek wystąpienia jakiegokolwiek błędu. Otóż jeśli zastosujemy zapis jak powyżej to treść błędu nie zostanie wstawiona do podanej sekcji. Po prostu stracimy informację o zaistniałej błędnej sytuacji. Takie podejście jest najczęściej stosowane gdyż zwykle nie chcemy pokazać osobie przeglądającej naszą stronę brzydkiego komunikatu o błędzie. Niemniej jednak jeśli po stronie serwera przechwytujemy wszelkie błędy i opakowujemy je w ładne komunikaty to możemy je również wyświetlić na stronie www.

<script type="text/javascript">
 function testAjax() {
  new Ajax.Updater({ success:'newsContent', failure:'errors' },
   '/prototypejs/data',
   { method: 'post', insertion: Insertion.Top }
  );
 }
</script>

Tym razem pierwszy argument przekazywany do konstruktora obiektu Ajax.Updater jest hashmapą, w której podajemy dwa identyfikatory sekcji. Jeśli nie wystąpi żaden błąd to pobrane dane zostaną wstawione do sekcji ‘newsContent’, natomiast jeśli pojawi się jakikolwiek błąd to jego treść znajdzie się w sekcji ‘errors’.
W drugim przykładzie pojawiła się jeszcze jedna nowość. Podajemy dodatkowy parametr żądania ‘insertion: Insertion.Top’, który informuje obiekt Ajax.Updater by wstawił pobraną treść “przed” tą, która znajduje się już w danej sekcji. Więc jeśli pojawi się jakiś błąd związany z żądaniem ajaxowym to informacja o błędzie zostanie wstawiona do sekcji gdzie, być może, mamy już inne komunikaty o błędach, na wyeksponowanej, pierwszej pozycji.

Inne dość często wykorzystywane zastosowanie technologii Ajax polega na okresowym uaktualnianiu części strony www, np. co minutę sekcja z najświeższymi informacjami ze świata Javy jest aktualizowana. Również tym razem Prototype dostarcza nam gotowy obiekt, który przy naszym minimalnym wkładzie zajmie się tym trudnym zadaniem ;). obiekt nazywa się Ajax.PeriodicalUpdater i stosuje się go podobnie do tych wcześniej opisanych.

<script type="text/javascript">
 function testAjax() {
  new Ajax.PeriodicalUpdater('dynamicContent',
   '/prototypejs/data',
   {method: 'get', frequency: 3, decay: 2}
  );
 }
</script>

Pierwszym argumentem jest identyfikator sekcji, do której dane będą wstawiane. Dalej mamy url oraz paczkę z parametrami żądania. W przykładzie podajemy parametr ‘frequency’, który określa jak często żądanie będzie przesyłane. W tym przypadku są to trzy sekundy. Kolejny parametr ‘decay’ mówi ile razy obiekt Ajax.PeriodicalUpdater ma zwiększyć parametr ‘frequency’ jeśli treść żądania, którą właśnie otrzymaliśmy jest identyczna z tą wcześniej otrzymaną. Pozwala to zmniejszyć obciążenie serwera na serwisach gdzie niusy nie pojawiają się zbyt często :).

Prototype zostało opracowane po to by ułatwić programowanie w JavaScript. Jego twórca miał kilka ciekawych pomysłów, które zostały udanie zaimplementowane. Zostało to zauważone również przez twórców innych bibliotek JavaScript (jak choćby Prototype Window), które wykorzystują Prototype jako swój szkielet, swoją bazę. W prosty sposób uzyskujemy dostęp do szerokiej gammy funkcji, którą zresztą możemy sami rozszerzać o nasze własne. Poprzez wsparcie dla technologii Ajax jej użycie staje się dziecinnie proste i bardzo wygodne. Za jedyną słabszą stronę Prototype można uznać jej dokumentację, która w niektórych miejscach nie jest zbyt obszerna. Niemniej jednak ubytek ten będzie nam zrekompensowany przez mającą się ukazać w najbliższym czasie książkę pt. ‘Prototype and script.aculo.us’.