Archiwa tagów: RequestFactory

Jak działa RequestFactory w GWT?

Jakiś czas temu pisałem na temat alternatywnego mechanizmu komunikacji klient-serwer w GWT, jakim jest RequestFactory. Omówiliśmy wtedy podstawy – zaimplementowaliśmy generyczną klasę DAO i wykonywaliśmy proste operacje CRUD. Przy okazji artykułu na temat JPA i walidacji encji pokazałem, jak w prosty sposób przeprowadzić walidację encji i zintegrować to z RequestFactory. Podczas omawiania relacji wiele-do-wielu i zapytań poprzez Criteria API w JPA 2.0 rozbudowaliśmy projekt wykorzystujący RequestFactory, jednak wtedy nie skupialiśmy się na części klienckiej, gdzie wykorzystywany jest tytułowy mechanizm. W żadnym z tych artykułów nie pisałem jednak na temat zasad działania RequestFactory, a domyślam się, że jesteś ciekaw jak to wszystko chodzi. W niniejszym wpisie chciałbym się skupić właśnie na stronie technicznej.

RequestFactory jest mechanizmem wprowadzonym w GWT 2.1 w celu dostarczenia alternatywy dla GWT-RPC. Alternatywy, dlatego że GWT-RPC dalej pozostaje podstawowym i najprostszym sposobem komunikacji klient-serwer, które nie jest jednak pozbawione kilku wad. RequestFactory jest przede wszystkim zorientowane na pobieranie danych (data-oriented) i doskonale integruje się z framework’ami bazodanowymi takimi jak np. Hibernate. Implementuje też walidację encji według normy JSR 303. Tak naprawdę mechanizm nadaje się do użytku od GWT 2.1.1, w której wprowadzono szereg udoskonaleń. W następnych wersjach pojawiały się mniejsze poprawki, zostały też zmienione pakiety wszystkich klas na mniej związane z samym GWT (z com.google.gwt na com.google.web.bindery), co sugeruje, że być może kiedyś zostanie wykorzystane poza GWT. W tym artykule opieram się na RequestFactory, jakie jest w GWT 2.4.

Czytaj więcej »

Co nowego w Sencha GXT 3?

sencha-logo

Długo oczekiwana kolejna wersja Ext GWT ukazała się niedawno pod nową nazwą: Sencha GXT 3. Obsunięcie wydania było dość spore, bo jak dobrze pamiętam, pierwsze wzmianki o GXT 3 mówiły jeszcze o wakacjach 2011. Czy warto było czekać? Jakie zmiany przynosi nowa wersja? Zaraz się o tym przekonamy.

GXT 3 miało w założeniach skupić się na integracji z rozwiązaniami, które pojawiły się w GWT 2.x. Ext GWT 2 pojawiło się jeszcze za czasów GWT 1.5, gdzie takie dobrodziejstwa jak RequestFactory, UiBinder, Autobean, Code Splitting czy wiele innych, były dopiero w zamysłach twórców GWT. Ext GWT wprowadzało więc własne rozwiązania, niektóre dość ciekawe, np. wsparcie Java Beans za pomocą BeanModel’i. Z czasem jednak w GWT pojawiały się natywne mechanizmy, które rozwiązywały poszczególne problemy na nieco niższym poziomie, chociażby mechanizm Autobean, który jest silnie wykorzystywany przez GWT RequestFactory. Kod Ext GWT był jednak tak zaprojektowany, że korzystanie z nowych udogodnień było bardzo trudne albo zupełnie niemożliwe.

Czytaj więcej »

JPA i walidacja encji w projekcie GWT

Całkiem niedawno opisywałem moje boje z mechanizmem RequestFactory, który okazał się być całkiem fajnym tworem. Za jego pomocą udało się nam wtedy stworzyć aplikację z serwisami zorientowanymi na dane, gdzie warstwę dostępu do danych zapewniał nam Hibernate. Aplikacja potrafiła wykonać jedynie podstawowe operacje CRUD na pojedynczej encji i już wtedy zapowiedziałem, że w dalszym ciągu czekają na nas relacje między encjami oraz walidacja encji. Dzisiaj będę kontynuować stworzony wtedy projekt i zajmę się drugim z zapowiedzianych tematów, czyli normą JSR 303 definiującą reguły sprawdzania poprawności obiektów. Walidacja nie będzie skomplikowana i ma na celu jedynie pokazanie działania wraz z mechanizmem RequestFactory.

Aby materiału na dzisiaj nie było za mało, pokażę jak skonfigurować projekt, aby skorzystać ze standardu JPA, którego API zastąpi nam Hibernate’a. Ten ostatni będzie dalej obecny pod postacią dostawcy implementacji JPA, jednak jak zauważymy później, kod źródłowy będzie całkowicie od niego niezależny. Przy okazji pokuszę się o małe porównanie JPA z Hibernate’m.

Zacząłem trochę inaczej niż zawsze, gdyż na wstępie zazwyczaj skupiam się na sensowności/celu zastosowania danej technologii, a nie na tym co będziemy robić. Jeśli czujesz się trochę zawiedziony, to już to nadrabiam :) Po co używać więc JPA, jeśli mamy w projekcie doskonale działającego Hibernate’a? Po co uczyć się nowego, nieco innego API? Czy użycie JPA ma jakieś zalety, ewentualnie wady? Odpowiedzi na te pytania mogą być różne i wszystko zależy od tego, jaką aplikację tworzymy i w jakim środowisku będzie ona pracować. Przede wszystkim należy pamiętać, że Hibernate nie jest jedynym narzędziem ORM’owym i istnieje cała masa alternatywnych rozwiązań. Możemy np. trafić do zespołu, który będzie faworyzował Oraclowego TopLink‚a, bądź rozwijanego przez fundację Apache – Open JPA. Możemy też być uzależnieni od środowiska, np. osadzenie aplikacji na serwerze Google App Engine będzie wymagało od nas użycia DataNucleus‚a.

Czytaj więcej »

Alternatywa dla GWT-RPC: RequestFactory

Prawdopodobnie znasz już dobrze mechanizm GWT-RPC, który dostarcza podstawowy sposób komunikacji klient-serwer w projekcie wykorzystującym GWT. Mechanizm ten z powodzeniem działa już od pierwszych wersji GWT i mając z początku alternatywę jedynie w postaci ręcznych zapytań do serwletów http, wygrywa prawie każde starcie. Nie ustrzegł się jednak kilku dość istotnych wad (wynikających z ogólnej architektury aplikacji GWT), które nie tyle co coś uniemożliwiają, ale bardziej uprzykrzają życie programiście. O ile GWT-RPC w wywoływaniu prostych akcji sprawdza się świetnie, to implementacja dobrej warstwy pobierania danych jest już dość trudna. Problem leży w tym, że GWT nie potrafi zserializować obiektów encji wybieranych wprost z bazy danych poprzez np. Hibernate’a, które zawierają dowiązania do innych obiektów encji będących z nimi w relacji. W praktyce sprowadza się to do tego, że nie można stosować mapowań relacji typu „lazy”, gdyż informacje o relacjach przechowywane w obiektach encji nie mogą być zserializowane i przesłane do strony klienckiej. Relacje można więc sobie odpuścić (co jeszcze sprawdzi się w małej aplikacji), bądź przesyłać przez RPC obiekty specjalnych klas DTO (Data-Transfer Object), które będą zawierały jedynie niezbędne dla widoku informacje – a tu czeka nas ręczne i wolne przepakowywanie atrybutów obiektów oraz mozolne tworzenie klas DTO. Da się z tym żyć, jednak da się zrobić lepiej! Czytaj więcej »