Speed Tracer jest dodatkiem do przeglądarki Google Chrome, który umożliwia analizę wydajnościową aplikacji webowych (nie tylko tych tworzonych w GWT). Speed Tracer pozwala na bardzo dokładne przyjrzenie się działającej aplikacji, wliczając w to np. obserwację zdarzeń JavaScript’owych. Zamiast wymieniać następne funkcjonalności narzędzia Speed Tracer, lepiej obejrzeć krótki (1:40) tutorial, gdzie wszystko jest bardzo ładnie pokazane. Warto zwrócić uwagę na naprawdę rewelacyjny interfejs aplikacji (zrobiony oczywiście w GWT ).

Myślą przewodnią nowej wersji GWT są szybsze aplikacje webowe. Szybsze zarówno w sensie szybkości ich działania, jak i szybkości developmentu. Lista zmian i nowości jest naprawdę duża. Zwrócę więc uwagę tylko na te najważniejsze (moim zdaniem).

Wersja 2.0 zdecydowanie poprawia cykl edycja/odświeżenie przez wprowadzenie tzw. development mode, który pozwala uruchomić w trybie debug projekt GWT w dowolnej przeglądarce, a nie jednej, dedykowanej (jak to było wcześniej). Oznacza to, że nareszcie można używać Firefoksa albo Chrome’a przy tworzeniu aplikacji GWT, a wraz z nimi -- pakietu ulubionych rozszerzeń na czele z Firebugiem . Nie obeszło się przy tej okazji bez zmiany Google Plugin for Eclipse, którym teraz można całkowicie kontrolować development mode z poziomu naszego ulubionego IDE . Jeszcze trochę z ciekawostek: development mode działa przez sieć. Można więc “przypiąć się” do zdalnej sesji przeglądarki. Wydaje się to szczególnie przydatne dla Linuksiarzy, którzy mogą tylko zgadywać jak wygląda ich aplikacji w IE pod Windows. (Nawet z GWT pewnych rzeczy się nie przeskoczy…)

Kolejna wielka zmiana, która dla mnie osobiście wydaje się być szalenie interesująca, to wprowadzenie nowego, deklaratywnego sposobu konstruowania interfejsu użytkownika o nazwie UiBinder. Założenie jest takie, by uczynić łatwą (a przy okazji trochę wymusić) separację warstwy widoku od logiki aplikacji. Pomysł polega na tworzeniu dwóch plików dla każdego komponentu warstwy prezentacji. Aspekty widoku zawarte są w pliku .ui.xml, który stanowi “mieszankę” normalnego HTML’a oraz komponentów widoku (ang. widgets). Sama implementacja logiki aplikacji pozostaje natomiast w osobnym pliku .java. Pozwala to na bardzo wyraźną separację tych dwóch zagadnień i np. bardziej efektywną współpracę programistów oraz web designerów. Dodatkowo, w czasie kompilacji sprawdzane są wszystkie referencje między powyższymi plikami, więc nie ma mowy o żadnych literówkach i tego typu błędach. Naturalnie, Google Plugin for Eclipse wspiera to rozwiązanie w 100%, wliczając refactoring, uzupełnianie kodu itd.

Najnowszy Google Web Toolkit wprowadza również tzw. layout panels, pozwalające na dokładne rozmieszczenie elementów w obrębie strony. Nie ma co ukrywać, że używając HTML i CSS jest to duży problem, który najczęściej wymusza użycie pewnych “sztuczek”. Nawet we wcześniejszych wersjach GWT czasami trzeba było pokombinować, żeby coś wyglądało tak jak trzeba we wszystkich przeglądarkach. Nowe rozwiązanie bazuje tylko na standardzie CSS, co ma dać layout nie tylko bardziej stabilny i przewidywalny, ale również szybszy (znane są dość spore problemy wydajnościowe przy zmianie rozmiaru okna przeglądarki we wcześniejszych wersjach GWT). Layout panels, jak łatwo się domyślić, doskonale sprawdzają się w połączeniu z UiBinder.

Kluczową nową funkcjonalnością w GWT 2.0 jest programowe rozdzielanie kodu (ang. code splitting). Polega to na wskazaniu (w kodzie źródłowym), które komponenty muszą być wczytane “z góry” i są konieczne do załadowania aplikacji, a które można doczytać chwilę później. To tak trochę jak oglądanie filmu na YouTube: nie trzeba przecież wczytać całości, żeby rozpocząć oglądanie. Moim zdaniem to świetne rozwiązanie. Mamy do czynienia przecież z aplikacjami webowymi; tutaj nie może być poczucia, że coś jest “instalowane”. Taką aplikację otwieramy i już ma być; każąc użytkownikowi czekać 15 sekund na pojawienie się pierwszego ekranu, możemy go łatwo stracić. Świetne wyniki tutaj uzyskał zespół Google Wave. W chwili obecnej skompilowana, pełna funkcjonalność tej aplikacji to “ważący” prawie 1500 kB JavaScript, który trzeba przecież ściągnąć od razu. Dzięki zastosowaniu rozdzielania kodu, początkowo użytkownik ma do pobrania 200 kB (a po kompresji już tylko 80 kB), a reszta jest “dociągana” w czasie, gdy zastanawia się gdzie by tu kliknąć. Różnica właściwie o rząd wielkości! Częściowo zasługa w tym również nowej wersji kompilatora, który tak czy inaczej “odchudza” kod nawet o ponad 20%. Można bez problemu skompilować starsze aplikacje. W moim ostatnim projekcie w GWT dało to oszczędność 14% (właśnie sprawdziłem ) tak po prostu, bez dotykania kodu źródłowego.

Z mniejszych zmian, nastąpiło ulepszenie mechanizmu paczek (ang. bundles). Teraz zamykać w paczki można nie tylko grafiki, ale pliki dowolnego rodzaju. Jest również specjalny rodzaj paczki dla plików CSS, który automatycznie optymalizuje dołączone arkusze stylów.

Podsumowując, GWT 2.0 wydaje się być znaczną aktualizacją tego produktu. Poprawiono zarówno efektywność pracy z technologią (co w konsekwencji zmniejsza koszt tworzenia oprogramowania), jak i wydajność samych aplikacji. Google Web Toolkit niewątpliwie potwierdza swoją mocną pozycję na rynku nowoczesnych technologii front-end’owych dla aplikacji webowych. Dla mnie osobiście, jest to już od dawna faworyt w tej kategorii, który coraz bardziej rośnie w siłę. Gorąco zachęcam do pobrania nowej wersji biblioteki i przyjrzenia się wprowadzonym zmianom. Zainteresowanych kieruję na stronę produktu.

Google GIN (GWT INjection) to stosunkowo młody projekt Google, wprowadzający do Google Web Toolkit możliwość wstrzykiwania zależności (ang. dependency injection). Oparty jest na Google Guice (o którym pisałem kilka tygodni temu) i zapewnia pewien podzbiór funkcjonalności tej biblioteki.  Po co więc GIN? Potrzeba wynika wprost ze specyfiki aplikacji tworzonych w GWT, która uniemożliwia zastosowanie “typowego” frameworka do wstrzykiwania zależności. Rozwinę ten temat za chwilę.

Póki co, nie ma możliwości pobrania skompilowanej biblioteki ze strony projektu (tak jak pisałem, jest to jeszcze wczesna faza rozwoju), więc pozostaje check out z publicznego repozytorium i własnoręczna kompilacja:

svn checkout http://google-gin.googlecode.com/svn/trunk/ google-gin-read-only
cd google-gin-read-only
ant dist

Zbudowanego JARa (./out/dist/gin.jar) oczywiście należy dołączyć do swojego projektu.

Zaczynamy!

Mamy już dostępne klasy GIN, więc można zaczynać. W regularnym Guice, po skonfigurowaniu zależności w klasie modułu i utworzeniu Injectora, obiekty pobiera się mniej więcej tak:

RegistrationService registrationService = injector.getInstance(RegistrationService.class);

W GWT jednak powyższy kod nie zadziała. Żeby być ścisłym: nie zadziała w komponentach po stronie klienta (ang. client-side). Jak wiadomo, aplikacja GWT dzieli się na stronę klienta i stronę serwera. Po stronie serwera nie ma żadnego problemu ze wstrzykiwaniem zależności. Obiekty są instancjonowane w rzeczywistym JRE (najczęściej w kontenerze serwletów) i żyją “normalnym” Javowym życiem. Można używać Guice, Spring albo dowolnego innego rozwiązania do wstrzykiwania zależności i będzie działać. Po stronie klienta wygląda to jednak zupełnie inaczej, ponieważ kod Java jest kompilowany do JavaScript, więc JRE nie istnieje (jest jedynie w niewielkim zakresie emulowane przez bibliotekę GWT). Standardowe użycie Guice nie zadziała więc z dwóch powodów:

• Na poziomie JavaScript nie istnieją klasy.
• Guice (podobnie jak większość tego typu rozwiązań) często korzysta z mechanizmu reflection Javy, który nie jest w ogóle emulowany w GWT.

GIN stosuje więc inny sposób na zapewnienie wstrzykiwania zależności. Na początek należy zaimportować moduł GIN we własnym module GWT.

<module>
  ...
  <inherits name="com.google.gwt.inject.Inject" />
  ...
</module>

Teraz funkcjonalność oferowana przez GIN jest dostępna w obrębie strony klienta aplikacji GWT. Dochodzimy jednak ponownie do momentu, gdy “jakoś” trzeba w końcu te zależności pobrać. W GIN używa się do tego specjalnej wersji Injectora — Ginjectora (który jednak de facto nie jest związany relacją dziedziczenia z tym pierwszym).

public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

Ginjector powinien oferować tylko komponenty potrzebne na etapie inicjalizacji aplikacji. Przy ich pobieraniu zostaną zainicjowane ich zależności, a więc również zależności tych zależności itd. W ten sposób zostanie zbudowany cały graf obiektów, a zależności automatycznie powstrzykiwane. W tym przypadku, komponentem potrzebnym na samym początku działania aplikacji jest ApplicationPresenter, który wyświetla ekran startowy. Zależności definiuje się dokładnie tak jak w Guice, czyli za pomocą adnotacji @Inject.

Jak wiadomo, Injector potrzebuje również modułu, w którym zawarte są informacje na temat komponentów.

public class ApplicationClientModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(ApplicationPresenter.class);
        // other bindings...
    }
}

Jak widać, moduł po stronie klienta w GWT dziedziczy z AbstractGinModule. Poza tym wszystko wygląda dokładnie jak w Guice. Istotnym niuansem związanym z modułami GIN jest fakt, że w przypadku nie odnalezienia powiązania dla klasy, automatycznie wywoływana jest dla niej metoda GWT.create(), przez co niektóre rzeczy (np. asynchroniczne interfejsy usług) będą działać nawet bez odpowiedniej deklaracji w klasie modułu.

Zdefiniowany moduł należy jeszcze skojarzyć z właściwym interfejsem Ginjector za pomocą adnotacji @GinModules.

@GinModules(ApplicationClientModule.class)
public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

W ten sposób, Ginjector jest w stanie skonfigurować całą aplikację na podstawie danych zawartych w określonym module. Aby to zrobić, należy go utworzyć za pomocą wywołania GWT.create() oraz pobrać początkowe obiekty.

public final class Application implements EntryPoint {
    public void onModuleLoad() {
        ApplicationGinjector injector = GWT.create(ApplicationGinjector.class);
        ApplicationPresenter applicationPresenter = injector.getApplicationPresenter();
        applicationPresenter.go(RootPanel.get());
    }
}

W ten sposób, cała procedura wstrzykiwania zależności ma miejsce już w czasie kompilacji. Użycie GIN nie jest więc związane z żadnym dodatkowym narzutem przetwarzania. (Wyszłoby na to samo, gdybyśmy konfigurowali komponenty ręcznie.)

Prawie jak Guice

Z użyciem GIN jest związanych kilka niuansów, o czym wspomniałem już na samym początku. GIN to nie jest mimo wszystko to samo co Guice, tylko dla GWT. Najbardziej istotne różnice w stosunku do Guice to:

• Zamiast typów Module i AbstractModule są GinModule i AbstractGinModule.
• Zamiast typu Injector jest Ginjector z adnotacją @GinModules.
• Niemożliwe jest użycie powiązania toInstance() i prawdopodobnie nigdy nie będzie możliwe (ze względu na to, że GIN działa w czasie kompilacji, a nie wykonania).
• Na chwilę obecną nie jest możliwe definiowanie własnych zasięgów.
• Nie ma adnotacji @ImplementedBy oraz @ProvidedBy.
• Brak obsługi zależności cyklicznych.
• Brak wsparcia dla AOP.

Warto jeszcze dodać, że istnieje sposób na współpracę z regularnym Guice za pomocą klasy GinModuleAdapter, dzięki której GinModule staje się dostępny jako zwykły Module. Można więc rozważyć utworzenie wspólnej części zależności w postaci GinModule. Ponadto, zrozumienie jak działa strona klienta w GWT na pewno pomoże uniknąć wielu potencjalnych problemów z GIN.

Podsumowanie

Jak widać, w GWT również można wygodnie wstrzykiwać zależności i to korzystając z bardzo przyjaznego API znanego z Guice. Mimo, że biblioteka ta jest jeszcze nieco niedojrzała i nie doczekała się nawet wersji 1.0, moim zdaniem warto się nią zainteresować i zastosować we własnych projektach w Google Web Toolkit. Używając jej przez ostatnie kilka miesięcy nie napotkałem żadnych problemów (w szczególności ze stabilnością), a znacząco ułatwiłem sobie pracę, rezygnując z ręcznego wstrzykiwania zależności. Myślę, że Google jeszcze nie raz zaskoczy nas różnymi ciekawymi dodatkami do GWT. Póki co, zapraszam na stronę domową projektu oraz zachęcam do własnych eksperymentów z Google GIN.

Google Guice to framework wspierający wstrzykiwanie zależności (ang. dependency injection) w aplikacjach Java. Można by powiedzieć: kolejny framework wspierający wstrzykiwanie zależności. Faktycznie, trzeba przyznać, że rynek Javowych rozwiązań tego typu jest dość mocno nasycony już od dłuższego czasu i oferuje pełen przekrój złożoności bibliotek, zaczynając od bardzo lekkich, takich jak choćby PicoContainer, a kończąc na pełnych stosach rozwiązań Java Enterprise ze Springiem na czele. Czy warto więc zawracać sobie głowę Guice’m? Moim zdaniem warto, bo zaproponowane przez Google’a rozwiązanie pokazuje nową jakość w implementacji wstrzykiwania zależności w aplikacjach Java, czyniąc ogromny użytek z typów generycznych oraz adnotacji. Guice jest przy tym lekki, ma proste API i bardzo szybko można się go nauczyć. Dlaczego warto to zrobić? Bo jest dobry. Kolesie z Google’a go używają. Musi być dobry. Poza tym, wygrał 18th Jolt Award w kategorii Libraries, Frameworks and Components. Musi być dobry.

Podstawy

W Guice występują dwie podstawowe konstrukcje opisujące wstrzykiwanie zależności. Pierwszą są moduły, które mówią co należy wstrzyknąć, a drugą jest adnotacja @Inject, która mówi gdzie należy wstrzyknąć. Proste. Zobaczmy jak to działa na przykładzie usługi rejestracji użytkowników.

public class RegistrationServiceImpl implements RegistrationService {
    private final PersistanceManager persistanceManager;
    private final MailService mailService;

    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }

    public void register(User user) {
        ...
    }
}

Jak widać naszą usługę specyfikuje kontrakt RegistrationService. Mamy jego implementację w postaci klasy RegistrationServiceImpl, która wymaga do działania usługi trwałości danych (PersistanceManager) oraz usługi do wysyłania maili (MailService). Chcielibyśmy, aby odpowiednie implementacje tych usług zostały automatycznie wstrzyknięte za pomocą parametrów konstruktora (adnotacja @Inject) już na etapie tworzenia usługi rejestracji. Spróbujmy opisać zależności między interfejsami a ich konkretnymi realizacjami za pomocą modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(RegistrationService.class).to(RegistrationServiceImpl.class);
        bind(PersistanceManager.class).to(HibernatePersistanceManager.class);
        bind(MailService.class).to(JavaMailService.class);
    }
}

Mamy nasz moduł. Jak widać, metoda configure() zawiera definicje kolejnych powiązań. Mamy więc usługę rejestracji określoną kontraktem RegistrationService z przypisaną naszą implementacją RegistrationServiceImpl. Mamy również usługę trwałości danych PersistanceManager zaimplementowaną w klasie HibernatePersistanceManager, która używa Hibernate’a do zapewnienia trwałości encji, oraz usługę MailService wraz z implementacją JavaMailService korzystającą z JavaMail do wysyłania poczty.

OK. Wystarczy już tylko użyć zdefiniowanego zespołu obiektów i przeprowadzić rejestrację użytkownika.

public class UserRegistrationExample {
    public static void main(String[] args) {
        Injector injector = Guice.createInjector(new MyModule());
        RegistrationService registrationService = injector.getInstance(RegistrationService.class);
        User user = new User("Michal", "Kalinowski");
        registrationService.register(user);
    }
}

To wszystko. Działa. “Prawie” jak w Springu, tylko zamiast trochę przydługawego pliku XML mamy elegancką implementację interfejsu Module w Javie, a zamiast identyfikowania obiektów za pomocą jakichś napisów mamy referencje do rzeczywistych klas. Myślę, że nie muszę wspominać jak ułatwia to refactoring. Jedyne do czego można się “przyczepić” to inwazyjność framework’a (odniesienia do API we własnych klasach), ale coś za coś. Wygoda jest niesamowita. Swoją drogą, pomysł na tyle przypadł do gustu kolesiom od Springa, że sami piszą już coś podobnego; nazywa się to Spring JavaConfig i powinno niedługo zostać oficjalnie wydane.

Oczywiście, proste powiązania interfejs <=> klasa i wstrzykiwanie zależności przez konstruktor to nie koniec możliwości Guice.

Powiązania

Oprócz prostych powiązań klasy z interfejsem, jest również kilka bardziej zaawansowanych konstrukcji.

Jedną z nich jest powiązanie adnotacją. Wyobraźmy sobie, że JavaMailService ma zostać użyty przez 2 różne usługi. Jedna z nich, nasz RegistrationService, do rozsyłania poczty powinna używać konta na Gmail’u, a inna – konta na Yahoo. Nic prostszego. Potrzebna nam dodatkowa adnotacja.

@BindingAnnotation
@Target( { FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface Gmail {
}

Modyfikujemy nieznacznie konstruktor naszej usługi rejestracji.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, @Gmail MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }
    ...
}

Oczywiście potrzebne jest również dodatkowe powiązanie w module.

bind(MailService.class).annotatedWith(Gmail.class).to(GmailJavaMailService.class);

Widać więc, że w Guice powiązanie jednoznacznie definiuje dopiero para adnotacji oraz typu.

Idźmy dalej. Jest możliwość stworzenia powiązania z konkretną instancją danego typu.

bind(String.class).annotatedWith(JdbcUri.class).toInstance("jdbc:mysql://localhost/application");

public class HibernatePersistanceManager implements PersistanceManager {
    public HibernatePersistanceManager(@JdbcUri String jdbcConnectionString) {
         ...
    }
    ...
}

Cool, huh? Można również zdefiniować w module własną metodę tworzenia obiektu. Używa się do tego adnotacji @Provides.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides
    PersistanceManager providePersistanceManager() {
        HibernatePersistanceManager persistanceManager = new HibernatePersistanceManager("jdbc:mysql://localhost/application");
        persistanceManager.initConnectionPool();
        return persistanceManager;
    }
}

Robi się bałagan w klasie modułu? Napiszmy zewnętrzne providery dla naszych komponentów.

public class DatabasePersistanceManagerProvider implements Provider<persistanceManager> {
    private final Connection connection;

    @Inject
    public DatabasePersistanceManagerProvider(Connection connection) {
        this.connection = connection;
    }

    public PersistanceManager get() {
        DatabasePersistanceManager persistanceManager = new DatabasePersistanceManager();
        persistanceManager.setConnection(connection);
        return persistanceManager;
    }
}

I jeszcze odpowiednie powiązanie.

bind(PersistanceManager.class).toProvider(DatabasePersistanceManagerProvider.class);

Można nawet zdefiniować providera bezpośrednio w interfejsie.

@ProvidedBy(DatabasePersistanceManagerProvider.class)
public interface PersistanceManager {
    ...
}

Warto zwrócić uwagę, że definicje powiązań w Guice “czytają się same”. Jest to ogromna zaleta tej biblioteki. Nie ma tu nawet co tłumaczyć.

Zasięgi

Domyślnie Guice dostarcza nową instancję klasy przy każdym zapytaniu do kontenera. Można jednak zażyczyć sobie za pomocą adnotacji @Singleton, by istniała dokładnie jedna instancja danego komponentu w obrębie całej aplikacji. W aplikacjach webowych, po dołączeniu odpowiedniego dodatku do deskryptora web.xml, można używać również zasięgu sesyjnego (@SessionScoped) oraz zasięgu pojedynczego żądania HTTP (@RequestScoped). Zasięgi można ustawiać na kilka sposobów. Można np. zrobić to na samej klasie.

@Singleton
public class JavaMailService implements MailService {
    ...
}

Nic nie stoi na przeszkodzie, by ustawić zasięg na metodzie tworzącej obiekt w obrębie modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides @Singleton
    MailService provideMailService() {
        ...
    }
}

Oczywiście, zawsze można zrobić to po prostu w definicji powiązania.

bind(MailService.class).to(JavaMailService.class).in(Singleton.class);

Wstrzykiwanie

W Guice dostępne są 3 standardowe metody wstrzykiwania zależności. Widzieliśmy już wstrzykiwanie przez konstruktor. Można również użyć do tego regularnej metody (niekoniecznie klasycznego settera).

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public void provideLogger(Logger logger) {
        ...
    }
    ...
}

Można również wstrzykiwać bezpośrednio do pola klasy, ale jest to zdecydowanie niezalecane.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject Logger logger;
    ...
}

Można w Guice również wstrzykiwać same providery.

public interface Provider<t> {
  T get();
}

Zapewniają one dodatkową elastyczność polegającą na tym, że kontener zwraca instancję komponentu-zależności wraz z każdym wywołaniem metody get(), a nie tylko jednorazowo na etapie tworzenia grafu obiektów.

public class DatabasePersistanceManager implements PersistanceManager {
    private final Provider<connection> connectionProvider;

    @Inject
    public DatabasePersistanceManager(Provider<connection> connectionProvider) {
        this.connectionProvider = connectionProvider;
    }

    public void persist(Object entity) {
        Connection connection = connectionProvider.get();
        ... // do something with provided connection
    }
}

Jakie to może mieć zastosowanie? Różne, przeróżne. Możemy potrzebować wielu instancji tego samego komponentu. Możemy zechcieć pomieszać komponenty różnych zasięgów (np. wstrzykiwanie danych użytkownika utrzymywanych w sesji HTTP do komponentu z zasięgiem Singleton). Możemy wreszcie użyć późnego ładowania (ang. lazy loading), jeśli konstruowanie komponentu-zależności jest kosztowne, a nie musi być wykonywane za każdym razem.

Czy to wszystko?

Oczywiście, omówiono tylko część możliwości Guice, aczkolwiek prawdopodobnie wystarczy to w 90% zastosowań. Widać więc, jak szybko można tę technologię przyswoić. Więcej informacji można odnaleźć w dokumentacji biblioteki. Znajduje się tam m.in. omówienie wsparcia dla programowania aspektowego oraz opis integracji Guice z rozwiązaniami webowymi. Warto tam zajrzeć.

Podsumowanie

Google Guice wydaje się stanowić bardzo ciekawą ofertę jako framework do wstrzykiwania zależności. Jeśli nie potrzebujemy bardzo kompleksowego rozwiązania takiego jak np. Spring, Guice powinien być w zupełności wystarczający. Jest bardzo lekki, prosty i ma niezwykle szybką krzywą uczenia. Dokładne przeczytanie tego posta powinno pozwolić na rozpoczęcie pracy, a w razie problemów zawsze pozostaje dokumentacja. Guice znacznie uprzyjemnia pracę programisty, pozwalając opisywać zależności i szczegóły ich wstrzykiwania za pomocą kodu Java “ozdobionego” adnotacjami i typami generycznymi, z zachowaniem jednocześnie deklaratywnego charakteru tego opisu. Jest to niewątpliwie znaczny krok do przodu. Uważam, że w dobrym kierunku.

.classpath
.project
.settings
.wtpmodules

do atrybutu svn:ignore katalogu każdego projektu w ramach przestrzeni roboczej (ang. workspace) i było po problemie. Aktualnie mamy w zespole jednego NetBeans’owca i do powyższej listy trzeba było dopisać jeszcze:

nbproject

Postanowiłem jednak przy okazji skonstruować kompletną listę wpisów do svn:ignore, która zawiera metadane 3 głównych IDE (Eclipse, NetBeans, IntelliJ IDEA). Dodatkowo dodałem target, jako standardowy katalog wyjściowy Maven’a oraz maskę *.log, bo takie pliki czasem również pojawiają się w repo. Mam nadzieję, że ta lista okaże się dla kogoś przydatna. Wygląda na to, że wystarczy ją “z góry” zaaplikować do wszystkich katalogów projektowych i mieć problem z głowy .

Ostateczna wartości atrybutu svn:ignore:

target
*.log
.classpath
.project
.settings
.wtpmodules
nbproject
*.ipr
*.iws
*.iml

Celem Mate jest zaproponowanie prostego i skutecznego mechanizmu zorganizowania przepływu sterowania (ang. control flow) w stylu MVC, z wykorzystaniem eventów Fleksa. Jest to jedna z głównych zalet Mate: zostaje wykorzystany już istniejący, sprawdzony i naturalny dla Fleksa mechanizm komunikacji między warstwami aplikacji. Framework nie wprowadza własnych rozwiązań, jeśli nie ma takiej potrzeby, co wspiera niezależność tworzonych modułów programowych.

Mate jest całkowicie przezroczysty z punktu widzenia aplikacji. Nie ma żadnych odniesień do klas frameworka zarówno w komponentach widoku, jak również biznesowych. Naturalnie, warstwa kontrolerów (w sensie MVC), musi być już powiązana z konkretną biblioteką i tak też jest w tym przypadku. Zastosowano jednak dość ciekawe rozwiązanie, polegające na zapisywaniu logiki sterowania w postaci tzw. map zdarzeń (ang. event map) definiowanych za pomocą XML. Określają one sekwencje poleceń do wykonania w odpowiedzi na wystąpienie konkretnych eventów. Przykładowo, nasza klasa zdarzenia mogłaby wyglądać tak:

package pl.espeo
{
    import flash.events.Event;

    public class AuthEvent extends Event
    {
        public static const LOGIN:String = "loginAuthEvent";

        public var username:String;
        public var password:String;

        public function AuthEvent(type:String, bubbles:Boolean = true, cancelable:Boolean = false)
        {
            super(type, bubbles, cancelable);
        }
    }
}

Blok przetwarzania dla tego zdarzenia mógłby wyglądać tak:

<EventMap ...>

    <EventHandlers type="{AuthEvent.LOGIN}">

        <RemoteObjectInvoker instance="{authService}"
            method="loginRemoteMethod" arguments="{[event.username, event.password]}">

            <resultHandlers>

                <MethodInvoker generator="{AuthManager}"
                    method="loginLocalMethod" arguments="{resultObject}"/>

            </resultHandlers>

        </RemoteObjectInvoker>

    </EventHandlers>

</EventMap>

Jeśli gdziekolwiek w naszej aplikacji zostanie “wyrzucony” event o typie AuthEvent.LOGIN, zostanie wykonany odpowiedni kod z mapy zdarzeń, który w tym przypadku wywołuje metodę loginRemoteMethod zdalnego obiektu authService, przekazując 2 argumenty: username oraz password. Po otrzymaniu wyniku tego wywołania, zostanie on następnie przekazany jako argument metody loginLocalMethod obiektu klasy AuthManager, która zrealizuje jakąś logikę związaną z obsługą wyniku logowania. Takie podejście często określa się mianem MVCS, gdzie to dodatkowe S oznacza Service. Mate promuje taką architekturę, oferując znaczniki obsługujące nie tylko zdalne obiekty, ale również WebService’y oraz dowolne inne usługi HTTP (np. w konwencji REST). Diagram przepływu sterowania w opisanym scenariuszu wygląda tak:

Jest to przypadek stosunkowo prosty. Możliwości Mate w zakresie kontroli przepływu sterowania są znacznie bardziej rozbudowane; jest np. możliwość zdefiniowania metody obsługi błędów zdalnych usług albo wywołanie odpowiednich metod logiki widoku w zależności od wyniku wykonania metod logiki biznesowej. Jeśli konieczne jest zaimplementowanie czegoś naprawdę skomplikowanego, na co tagi Mate mogą nie pozwolić, zawsze można napisać własną metodę w ActionScript i wydelegować przetwarzanie do niej. Możliwości są tutaj w zasadzie nieograniczone. Kolejny wielki plus Mate: bardzo duża elastyczność.

Oprócz realizacji architektury MVC(S), Mate zapewnia również implementację mechanizmu wstrzykiwania zależności (ang. dependency injection). Ponownie, nie ma tutaj ingerencji we właściwy kod logiki biznesowej czy widoku; zależności do wstrzyknięcia definiuje się w mapach zdarzeń. Mate oferuje tutaj jedynie sposób deklaratywnego opisu powiązań między obiektami. Właściwe wstrzykiwanie jest po stronie Fleksa i jego atrybutu [Bindable]. To kolejny przykład nieinwazyjności tego frameworka. Jeśli platforma programowa realizuje jakąś funkcjonalność dobrze, po co to powielać? Spójrzmy, jak łatwo w Mate wstrzykuje się obiekt bieżącej sesji (pole currentSession obiektu klasy SessionManager) do menedżera autoryzacji (pole session obiektu klasy AuthManager):

<EventMap ...>

    <Injectors target="{AuthManager}">

        <PropertyInjector source="{SessionManager}"
            sourceKey="currentSession" targetKey="session" />

    </Injectors>

</EventMap>

Podsumowując, Mate to naprawdę świetny pomysł na wprowadzenie do własnego projektu dobrej, spójnej architektury MVC. Promuje najlepsze praktyki rozwiązywania typowych problemów, występujących w każdej aplikacji, np. problemu zależności między komponentami z rozwiązaniem w postaci wstrzykiwania zależności. Zapewnia ogromną elastyczność, pozwalając w elegancki sposób wspomóc framework własnym kodem w ActionScript, jeżeli dostarczone tagi okażą się niewystarczające. Jest przy tym całkowicie nieinwazyjny, przez co komponenty widoku i logiki biznesowej mogą być ponownie wykorzystane.

Mimo młodego wieku, Mate oferuje naprawdę dużą funkcjonalność, która jest cały czas rozszerzana. Śledząc stronę projektu i jego forum, można przekonać się, że projekt żyje, jest rozwijany, a społeczność zadowolonych programistów-użytkowników Mate nieustannie się powiększa. Myślę, że warto się nim zainteresować. Już teraz jest bardzo poważnym konkurentem takich rozwiązań jak Cairngorm czy PureMVC. Jeśli projekt nie wytraci impetu to może już niedługo być najchętniej wybieranym frameworkiem dla nowopowstających projektów Fleksowych.

Gorąco zachęcam do odwiedzenia strony domowej projektu:
http://mate.asfusion.com/

Zasadnicza koncepcja jest prosta: użyć Flex jako front-end, Grails jako back-end i zintegrować jedno z drugim. Brzmi łatwo, ale bardziej doświadczeni developerzy (szczególni Ci, zajmujący się systemami rozproszonymi) zapewne dostali właśnie dreszczy, widząc magiczne słowo: “zintegrować”. Mam dobrą wiadomość: w tym przypadku integracja obu technologii jest łatwa, szybka i przyjemna. Wydaje mi się, że jest to jedna z głównych przyczyn rosnącej popularności omawianego rozwiązania.

Na początek warto zastanowić się po co właściwie nam Grails + Flex. Można przecież zbudować aplikację internetową w Grails od początku do końca, podobnie zresztą jak we Flex. Użycie kombinacji obu technologii ma sens w przypadku, gdy robimy RIA, ale implementację logiki biznesowej chcielibyśmy pozostawić na serwerze, a także, dodatkowo, chcemy to wszystko wykonać w możliwie dobrych technologiach, które całą sprawę nam ułatwią, a nie utrudnią i zapewnią, przy okazji, realizację kilku wymagań niefunkcjonalnych (jak choćby duża przenośność), na których na pewno nam zależy. Grails + Flex = dokładnie to. Flex jest świetną technologią, która oferuje nam pełną potęgę graficzną Flash’a, ale w formie przyjaznej programiście (a nie grafikowi). Grails natomiast pozwala wykorzystać w całości moc platformy Java EE (czyli również jej bogactwo bibliotek, framework’ów oraz innych narzędzi), czyniąc jednak programowanie łatwiejszym i szybszym dzięki takim cechom jak choćby zasady DRY (Don’t Repeat Yourself – Nie powtarzaj się) i Convention Over Configuration (Konwencja ponad konfigurację), język programowania Groovy czy technologie Spring i Hibernate podane “na tacy”, bez żadnego dodatkowego wkładu pracy w konfigurację itp. Więcej na ten temat przeczytać można we wcześniejszym wpisie Pawła.

Teraz czas na właściwą integrację. Po stronie Grails nie musimy właściwie nic robić, bo wszystko załatwia jeden plug-in. Wystarczy go zainstalować, wydając z konsoli (w katalogu głównym projektu Grails) polecenie:

grails install-plugin flex

oraz dodać w klasie usługowej (ang. service), która implementuje logikę biznesową, którą chcemy udostępnić aplikacji Flex, jedno pole statyczne:

static expose = ['flex-remoting']

i to wszystko! Usługa będzie od teraz udostępniona. Powiedzmy, że wygląda ona tak:

class HelloService {
    static expose = ['flex-remoting']
    def hello() {
        return "Hello World!"
    }
}

W aplikacji Flex wystarczy powołać obiekt RemoteObject:

<mx:RemoteObject id="myService" destination="helloService"/>

by móc korzystać z naszej usługi. Przykładowa aplikacja może wyglądać tak:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:RemoteObject id="myService" destination="helloService"/>
    <mx:Button label="Hello" click="myService.hello()"/>
    <mx:TextInput text="{myService.hello.lastResult}"/>
</mx:Application>

Nic dodać, nic ująć. Zero konfiguracji. To po prostu działa… i już!

Ale właściwie… jak to działa? Otóż nie ma tu żadnej “magii”, wbrew temu co widać na pierwszy rzut oka. “Pod maską” siedzi magiczny komponent BlazeDS i odrobina Convention Over Configuration. BlazeDS jest technologią serwerową, która obsługuje styk Grails <=> Flex (a tak naprawdę to Java <=> ActionScript) poprzez implementację mechanizmu RPC, tak jak to pokazano wyżej. Przez “obsługuje” rozumiem wszystko, co jest potrzebne do zdalnego wywołania metody logiki biznesowej: udostępnienie usługi w sieci (pod konkretnym URL), ustalenie protokołu komunikacyjnego ponad warstwą HTTP oraz zapewnienie konwersji typów między światem Java, a światem ActionScript. Część “magii”, jak sądzę, została już wyjaśniona. Idźmy dalej. Przenieśmy naszą aplikację Flex do osobnego projektu, czyli rozdzielmy całość na projekt Grails i projekt Flex. Okaże się, że nagle wszystko przestało działać, co zresztą nie dziwi, bo niby skąd aplikacja Flex ma mieć pojęcie co zrobić z:

<mx:RemoteObject id="myService" destination="helloService"/>

skoro nie wie gdzie jest helloService (przypominam, że aplikacja Grails jest już osobnym projektem). Oto rozwiązanie: uruchamiamy naszą aplikację Grails poleceniem:

grails run-app

i (zakładając, że aplikacja jest dostępna pod adresem http://localhost:8080/hello) modyfikujemy powyższą definicję obiektu RemoteObject:

<mx:RemoteObject id="myService" destination="helloService"
    endpoint="http://localhost:8080/hello/messagebroker/amf"/>

Mamy URL, pod którym udostępnione są nasze obiekty usługowe, i mamy “magika” łączącego świat typów Java ze światem typów ActionScript, którym są biblioteki BlazeDS. Dodam tylko (żeby nie pozostawić żadnych wątpliwości), że protokołem komunikacyjnym nad warstwą HTTP jest AMF (ang. ActionScript Message Format), którym “rozmawiają” aplikacja Flex (wykonująca zdalne wywołanie metody) i BlazeDS (uruchamiający na żądanie metody logiki biznesowej i zwracający ich rezultat).