Groovlety

Minęło sporo czasu od kiedy ostatni raz bawiłem się Grailsami i Groovym. Ostatnio jednakże doświadczenie pokazało, jak świetnym udogodnieniem dla programisty Javy może być potęga języków skryptowych. Pytanko do czytelników – czy kiedykolwiek pisaliście prototyp działającej aplikacji?

Jeśli aplikacja ma być zaakceptowana przez szereg ludzi, zgodna z 4 projektami/analizami wymagań/raportami to wiadomym jest, że wygodnie jest stworzyć coś, co będzie udawało gotowy produkt na tyle, aby ludzie nie będący programistami stwierdzili, że tak to ma być i projekt startuje. Można ograniczyć się do zwykłych obrazków i prezentacji, ale to dość słabe rozwiązanie. Drugą możliwością jest oparcie tego o czysty HTML oraz JavaScript. Rozwiązanie o niebo lepsze i ma też dużą zaletę – ruszy na każdym możliwym sprzęcie, w każdym możliwym miejscu (mikrofalówki się nie liczą). Do wielu rozwiązań wystarczą – jeśli jednak nasze potrzeby są bardziej rozbudowane, warto uderzyć w rozwiązania bardziej poważne, a konkretniej – Groovlety.

Można domyślić się, że chodzi o język Groovy wykorzystywany w formie prostego szkieletu dla aplikacji internetowych. W przypadku prostego prototypu aplikacji jest jak znalazł – tym bardziej, że można spokojnie zaprojektować już strukturę logiczną strony (czyli budowę linków, podział na akcje) i następnie na tak przygotowanym prototypie rozpocząć budowę aplikacji. Za pomocą samych groovletów jest to dość łatwo osiągalne –  jednakże obracamy się wciąż w obrębie jednej klasy/pliku i nie do końca sprzyja to tworzeniu warstwy widoku (a przecież o to głównie w prototypach chodzi). Dlatego też dodatkowo pokażę jak do naszych groovletów podpiąć warstwę widoku natywną dla języka Groovy – pliki gsp.

Zasadniczo niezależnie od wybranego IDE tworzymy nowy projekt aplikacji webowej. Ja użyłem do tego Eclipsa – zwykły Dynamic Web Project da radę. Struktura katalogów jest prosta jak świat według PiSu – w odróżnieniu jednakże od zwykłego serwletowego projektu musimy poinformować nasz kontener (a nie wspomniałem, do uruchomienia wystarczy czysty kontenerek – Tomcat lub Jetty) o tym, aby używał Grooviego. By to osiągnąć do katalogu /WEB-INF/lib dorzucamy plik JAR z najnowszą wersją języka Groovy (w momencie pisania tego tekstu jest to wersja 1.7.6), którą to pobrałem z tej oto lokacji. Do tego będziemy potrzebować (przynajmniej w przypadku Tomcata) JARa z ASM oraz ANTRL. Można te pliczki ciągnąć oddzielnie, istnieje też (jak  dowiedziałem się poniewczasie) paczka z Groovym, która zawiera wszystkie poboczne biblioteki. Tutaj już sami ogarnijcie co lepsze – w zależności od ustaleń serwera i CLASSPATH. Ja swoje pliki wrzuciłem do tego samego katalogu co plik z Groovym i obydwa dodałem do bibliotek projektu (prawyklik na projekcie i dalej chyba wiadomo). Musimy oczywiście wyedytować plik web.xml. U mnie wygląda on tak:

 

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" 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">
	<display-name>Groovlets</display-name>
	<servlet>
      <servlet-name>GroovyServlet</servlet-name>
      <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>GroovyTemplate</servlet-name>
        <servlet-class>groovy.servlet.TemplateServlet</servlet-class>    
	</servlet>
    <servlet-mapping>
        <servlet-name>GroovyServlet</servlet-name>
        <url-pattern>*.groovy</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>GroovyTemplate</servlet-name>
        <url-pattern>*.gsp</url-pattern>
    </servlet-mapping>   
</web-app>

 

Zastanówmy się przez chwilkę, co konkretnie chcemy osiągnąć. Potrzebujemy narzędzia do prototypowania aplikacji, zatem dobrze by było, aby ten prototyp nie tylko wyglądał i zachowywał się jak przyszła aplikacja, ale też by od strony kodu architektura wyglądała podobnie. Potrzebujemy zatem nie tylko serwletu jako takiego, ale również oddzielenia warstwy widoku – i osiągniemy to, jednakże nie poprzez brutalne wrzucanie wszystkich plików *.gsp do WEB-INF, ale stworzymy odpowiednią strukturę. Konkretnieje nasze groovlety uznamy za kontrolery, zaś odpowiednim ich metodom dodamy oddzielne pliki widoku (tak jak czyni to choćby stary poczciwy Zend Framework z PHP). Pliki te jednakże umieścimi w odpowiednich folderach, aby w kodzie panował porządek. Do dzieła.

Nie będziemy rozszerzać serwletu bazowego by mapować klasy serwletów do odpowiednich pakietów źródłowych – na razie będziemy wrzucać wszystkie pliki serwletów do /WebContent, zaś pliki z widokiem będą posiadały swoje oddzielne katalogi (per kontroler). Tworzymy plik IndexController.groovy i wypełniamy go taką treścią:

def _forward(page, req, res){
  def dis = req.getRequestDispatcher(page);
  dis.forward(req, res);
}

_forward("index/index.gsp", request, response )

Co my tu mamy? Stworzyliśmy klasę z kontrolerem – na razie jest on odpowiedzialny za tak naprawdę 1 rzecz – wyrenderowanie odpowiedniego pliku . Plik ten jednakże wpierw musimy stworzyć – w katalogu /WebContent tworzymy katalog index i do niego wrzucamy plik index.gsp. Ja wypełniłem go na razie prostym tagiem HTMLa. Odpalamy Tomcata i lecimy pod adres:   http://localhost:8080/Groovlets/IndexController.groovy. Rzecz jasna adres może się różnić w zależności od konfiguracji serwera i nazwy projektu. U mnie dzięki temu na ekranie można zobaczyć taki widok:

I jesteśmy tym samym w domu. Jak widać w kodzie Groovletu mamy dostępnych kilka predefiniowanych zmiennych. Jak widać powyżej ja użyłem request oraz response. Mamy też obiekty kontekstu, sesji i kilka innych. Po listę tychże odsyłam do oficjalnej strony.

Co nam teraz pozostało? To już zależy od developera – możemy oprzeć się na istnieniu jednego kontrolera/serwletu, który będzie forwardował żądania do odpowiednich metod lub w ogóle klas w zależności od przekazanych parametrów. Możemy pobawić się z modyfikacją bazowej klasy serwletu i stworzyć coś na kształt własnego “pseudo-frameworka”, aby np. stworzyć mapowanie adresów podobne do tego w Grailsach. Trzeba by też pomyśleć o stronie powitalnej (lub forwardowaniu żądań domeny do naszego kontrolera). Najważniejszym jednakże faktem jest to, iż posiadamy gotowe narzędzie do stworzenia prototypu aplikacji z oddzielnymi warstwami (MVC to jeszcze nie jest, ale niewiele brakuje), zaś w widoku mamy pliki gsp, które są na pewno bardziej wdzięczne niż jsp czy czysty HTML.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s