Tworzenie aplikacji GUI w Groovy wymaga pobrania dodatkowych bibliotek - SwingXBuilder, SwingX, JGoodies Forms i Glazed Lists. Ich instalacja w Groovy (teraz jesteśmy na poziomie Groovy, a nie Grails) to umieszczenie ich w CLASSPATH, w <katalog-domowy-groovy>/lib lub <katalog-domowy-użytkownika>/groovy/lib.
SwingXBuilder to Groovy "builder" (jak ja miałbym to przetłumaczyć?! Może budowniczy...Bob?!) do tworzenia interfejsu użytkownika w Swingu. Pod spodem korzysta z biblioteki SwingX. JGoodies FormLayout jest popularnym zarządcą układu (ang. layout manager) dla Swinga. Glazed Lists natomiast jest bardzo zaawansowanym komponentem Swing do tworzenia tabel. Ze SwingXBuilder oraz komponentami SwingX tworzymy okienka dialogowe, podpowiedzi i pasek statusu, z Glazed Lists sortowane tabele, a JGoodies Forms obsłuży ich rozkład.
Do skryptu Groovy przekazywany jest parametr args, który jest listą parametrów wejściowych skryptu, np. (Listing 13-1):
if (args.size() < 2) {Uruchomienie skryptu Groovy to wykonanie groovy <nazwa-skryptu> <parametry>.
...
}
def userid = args[0]
def password = args[1]
W skryptach możemy skorzystać z narzędzia JLine do obsługi wprowadzanego przez użytkownika tekstu z linii poleceń, np. ukrycia wpisywanego hasła, np. (Listing 13-2):
import jline.ConsoleReaderJLine jest dystrybuowany z Groovy.
ConsoleReader cr = new jline.ConsoleReader()
print "User id: "
def userid = cr.readLine()
print "Password: "
def password = cr.readLine(new Character('*' as char))
// można również połączyć print i readLine
def uzytkownik = cr.readLine("Użytkownik: ")
Groovy może wszystko, co potrafi Java. Według autorów, tworzenie GUI w Javie to wybór między Java Swing a Eclipse Standard Widget Toolkit (SWT). Można, więc zamiast programować w Javie i korzystać ze wspomnianych bibliotek, programować w Groovy. Znaczne uproszczenie daje skorzystanie z "budowniczych" (ang. builders) w Groovy - SwingBuilder, SwingXBuilder czy JideBuilder dla Swing oraz SwtBuilder dla SWT. Rozkład komponentów, definiowanie ich akcji jest znacznie prostsze z ich pomocą, np. (Listing 13-5):
swing = new SwingXBuilder()Potwierdzeniem możliwości SwingXBuilder jest wersja Groovy Console, która znajduje się w repozytorium SwingXBuilder w demos/Console.
swing.lookAndFeel('system')
swing.action(id: 'exitAction',
name: 'Exit'
closure: this.&exit,
mnemonic: 'x',
accelerator: 'F4'
shortDescription: 'Exit SimpleUI'
}
void exit(event) {
System.exit(0)
}
Podsumowaniem rozdziału są zdania
"The important thing to remember is that "Groovy is Java" and that allows you to use any of the Java components and libraries you want to build an application."
oraz
"Our goal was to give you a sample of what is possible. You are only limited by your imagination."
Wyjdzie w praniu, jak bardzo się (nie)pomylili. ;-)
W ten sposób, dobrnąłem do samego końca książki Beginning Groovy and Grails: From Novice to Professional, którą wpisuję na listę książek przeczytanych "od deski do deski". Czy warto było? Zdecydowanie TAK! Sama dokumentacja Grails jest bardzo wartościowym źródłem wiedzy o nim, ale książki mają to do siebie, że ich treść prowadzona jest jak pewien projekt, w którym kolejne rozdziały dotykają funkcjonalności wymaganej w kolejnych iteracjach rozwoju aplikacji. Tak też było w przypadku tej książki. Dodatkowo miałem okazję poznać wiele wspomagających projektów, o których nawet nie wiedziałem, że istnieją (!) Jeśli przyjdzie mi realizować projekt aplikacji webowej Grails będzie z pewnością mocnym kandydatem do jego realizacji (obok Apache Wicket, JBoss Seam i JSF - chociaż samo JSF wydaje się być bardzo prymitywne przy poprzednikach). Grails, swoją funkcjonalnością nie odbiega od innych znanych mi szkieletów webowych, a w wielu miejscach przebija ich o głowę (chociażby scaffolding, klasy dziedzinowe z metodami bazodanowymi, "builders", zintegrowany tandem Hibernate+Spring Framework czy Groovy jako język programowania), a jedynym problemem, jaki mógłbym podnieść teraz, to brak własnego doświadczenia wdrożeniowego, w którym mógłbym sprawdzić siłę Grails w boju. Po lekturze książki nie spodziewałbym się wielu wpadek, ale diabeł tkwi w szczegółach i nie twierdzę, że ich nie byłoby. Może dzięki zmniejszeniu ilości czasu potrzebnego na stworzenie aplikacji (dzięki wspomnianym wcześniej cechom Grails) miałbym czas na rozwiązanie potencjalnych niedoskonałości? Mam wrażenie, że tak. A jak Wam idzie wdrażanie aplikacji opartych na Grailsie? Wciąż działają? Z kim konkurowały podczas etapu wyboru tego właściwego szkieletu webowego?
Jak już pisałem strona GeeCON jest napisana w Groovy i Grails, za jej pisanie zabrałem się po przeczytaniu jednej książki o Groovy (nie Grails).
OdpowiedzUsuńFramework poznawałem jedynie z materiałów na stronie projektu, wystarczyło to jednak aby sprawnie napisać stronę w jeden weekend :)
Niestety jest pewien problem z hostingiem Javowym, stąd też w pewnym momencie zastanawiałem się czy nie przepisać tego w Rubym i Merb, na całe szczęście tego nie zrobiłem :)
Co do samego Groovy'ego to używam go obecnie jako język w którym piszę testy jednostkowe w projektach w których biorę udział. Sprawdza się tam idealnie!
Pozdrawiam,
Radek
PS. Szkoda, że nie przedstawiłeś żadnego praktycznego przykładu dotyczącego Groovy i Grails.
Z przykładami wstrzymałem się, bo nie dałbym rady na serce tak się ekscytować tymi uproszczeniami w Grails ;-) Książkę mam za sobą i pomysł na aplikację również, więc praktyka przyjdzie niebawem. Przyszłość należy do Grails!
OdpowiedzUsuńto ja tylko dodam, że klienci przychodzą do sklepu. Z aplikacji korzystają klienty.
OdpowiedzUsuń