Wieści z rozdziału 1. w "The Definitive Guide to Grails, 2nd Ed."

Zgodnie z zapowiedzią zabrałem się za lekturę książki The Definitive Guide to Grails, 2nd Ed. autorstwa Graeme Rochera oraz Jeffa Browna. Obaj panowie wielce zasłużeni dla projektu Grails, więc nie byłem wcale zdziwiony sposobem, w jaki obaj przedstawiają go - w samych superlatywach i to w niezwykle kwiecistym języku angielskim. Można połączyć przyjemne - poznawanie Grails - z pożytecznym - nauka zwrotów angielskich (nawet pojawiło się zdanie z Future perfect!). Czyta się niezwykle przyjemnie i jakkolwiek wszystko to już czytałem w poprzedniej książce o Grails - Wieści z rozdziału 4. "Introduction to Grails" z "Beginning Groovy and Grails" oraz Tworzenie interfejsu użytkownika w Grails - rozdział 5 z "Beginning Groovy and Grails", to wtedy były dwa rozdziały, a teraz jeden. To samo, a jakby inaczej.

Rozdział 1. "The Essence of Grails" rozpoczyna się mottem Leonardo da Vinci "Simplicity is the ultimate sophistication.", które w zasadzie podsumowuje peany autorów na temat prostoty jaką wprowadziły Groovy i Grails w życie programistów javowych. Należy przypomnieć, że Ci, którzy nie mają przyjemności pracować z tandemem Groovy/Grails jedynie "conjure up unknown horrors and nightmarish thoughts of configuration, configuration, configuration." (z Grails, the Platform, str. 3). Tak przy okazji, w życiu nie spotkałem tego zwrotu conjure up.

Autorzy rozpoczynają książkę przedstawieniem genezy Grails - "dramatically simplify enterprise Java web development." (str. 1). Z konwencją-nad-konfiguracją (ang. CoC - Convention over Configuration), DRY (ang. Don't Repeat Yourself), domyślnymi ustawieniami, gotowym do użycia środowiskiem na bazie Spring Framework, Hibernate, SiteMesh, Jetty, HSQLDB oraz Groovy (przez co mamy dostęp do pełnego zestawu możliwości platformy Java) możemy czerpać garściami z podobnych rozwiązań jak Ruby on Rails, Django czy TurboGears (wspomina się później również CakePHP), które do tej pory były poza zasięgiem programistów javowych. Z Grails mamy tą kwestię rozwiązaną. Jako programiści aplikacji grailsowych nie musimy wiedzieć, że nasze rozwiązania bazują na Spring Framework oraz Hibernate (a już na pewno nie musimy schodzić na poziom ich konfiguracji w XMLu), ale gdy poczujemy taką potrzebę możemy je dodatkowo "dostroić" do naszych potrzeb. Za autorami - Grails jest "a platform with ambitious aims to handle everything from the view layer down to your persistence concerns." (str. 3) oraz jako programista "you have the assurance that you are standing on the shoulders of giants with the technologies that underpin Grails: Spring, Hibernate, and, of course, the Java platform." (str. 1). Mało? Mnie wystarczy. Chyba nie da się nie zauważyć, że trudno byłoby znaleźć mi w tej chwili lepsze rozwiązanie do tworzenia aplikacji webowych niż Grails.

Po tych wyniesieniach przechodzimy do zapoznania się z krokami do utworzenia pierwszej niezwykle trywialnej, bo składającej się z pojedynczego kontrolera, aplikacji grailsowej - gTunes. Aplikacja gTunes to sklep muzyczny ala Apple, Amazon czy Napster. Oczywiście krótki przerywnik w postaci instrukcji instalacji Grails - pobieramy paczkę dystrybucyjną z http://grails.org, rozpakowujemy do wybranego katalogu, ustawiamy zmienną GRAILS_HOME i PATH, i tyle. Przepis na aplikacyjkę to grails create-app, grails create-controller, grails test-app, aby zakończyć grails run-app. Nie wiemy, po co nam każde z tych poleceń?! Wystarczy grails help <polecenie>. Warto podkreślić, że książka opisuje rozwojową wersję Grails 1.1 (aktualnie mamy dopiero Grails 1.1 beta 3). Nie od parady nosi tytuł "The Definitive Guide to Grails".

Jakkolwiek możemy korzystać z pomocy poleceń grails (który jest skryptem Gant) to mamy również możliwość tworzenia wszystkiego "z ręki". Wybór należy do nas samych.

Podkreśla się znaczenie testów jednostkowych i integracyjnych, chociażby ze względu na dynamiczną naturę Groovy, który, podobnie jak inne języki skryptowe - Ruby i Python - nie posiadają takiego arsenału weryfikacyjnego jak statycznie typowane języki, np. Java. Właśnie z tego powodu wielu wybiera Groovy, ale ma to swoje ograniczenia - większość kontroli poprawności programu przesunięta jest na czas jego uruchomienia. Jeśli kiedykolwiek myślałeś o znaczeniu testów w projekcie, teraz masz powód. Szczęśliwie Grails tworzy odpowiedni byt (kontroler, klasę domenową) wraz z odpowiadającymi testami jednostkowym i integracyjnym.

Podczas grails create-controller tworzony jest kontroler z domyślną akcją (domknięciem) index. Zgodnie z konwencją Grails wykonanie index to wyświetlenie strony grails-app/views/<nazwa-kontrolera (bez Controller)>/index.gsp. Poznajemy metodę render, która m.in. wyświetla tekst na stronie.

Wykonanie testów jednostkowych w Grails wiąże się z taką jego konfiguracją opartą na bytach-zaślepkach (ang. mocks and stubs), które symulują faktyczne zachowanie bytu, dla którego stanowią zaślepkę. Grails umożliwia sprawdzenie, czy wykonanie żądania zwróci zadany tekst (zadaną stronę) przez (Listing 1-9):

 controller.index()
 assertEquals "tekst z render", controller.response.contentAsString

Grails podstawia za servletowy HttpServletResponse springowy MockHttpServletResponse z metodą contentAsString. Wykonanie grails test-app to uruchomienie wszystkich testów jednostkowych, ale możliwe jest również zawężenie testów do pojedynczego podając parametr do grails test-app <nazwa-klasy-testowej (bez Tests)>. W katalogu test/reports znajdują się raporty z wykonania testów w formacie XML, HTML i TXT.

Uruchomienie aplikacji to wykonanie polecenia grails run-app (domyślnie na porcie 8080). Jeśli podamy parametr -Dserver.port=<numer-portu>, obowiązującym portem będzie podany.

W ten sposób poznaliśmy podstawowe tajniki tworzenia aplikacji. W kolejnym rozdziale autorzy przygotowali dla nas zestaw cudów do sprawnego tworzenia aplikacji typu CRUD z "some of Grails' Create, Read, Update, Delete (CRUD) generation facilities that allow you to flesh out prototype applications in no time" (str. 15). Jeju, jak tak dalej pójdzie to połowa działu rozwoju pójdzie z torbami (!) W tych czasach należy jeszcze bardziej uważać, co się proponuje w projekcie, bo z 30-osobowego zespołu może zostać trzech i jeszcze dwóch może się nudzić. ;-)