Some of posts from this blog has been moved to dywicki.pl. You will be automatically redirected to new blog if you would submit comment.
New posts are published on dywicki.pl, this blog contains old content related to Code-House company.


Niektóre posty z tego bloga zostały przeniesione do dywicki.pl. Zostaniesz automatycznie przekierowany jeśli bedzięsz chciał dodać komentarz.
Nowe posty sa publikowane na dywicki.pl, ten blog zawiera stare treści związane z firmą Code-House.

GWT oraz implementacje MVC

GWT, czyli Google Web Toolkit to nic innego jak zbiór komponentów, które można użyć podczas tworzenia aplikacji. GWT jest łatwe, kod tworzy się szybko i łatwo uruchamia chociażby z poziomu Mavena, jednakże największym problemem nie jest to jak stworzyć okienko, ale jak zorganizować projekt. W tym poście postaram się przedstawić kilka gotowych bibliotek, z którymi się zetknąłem podczas swych bojów z budowaniem sporej aplikacji.


Ilość implementacji MVC dla GWT jest dosyć duża a temat był poruszany na zagranicznych blogach już nie jeden raz, wystarczy zajrzeć na poniższe strony:

  • W marcu 2009 Matt Raible opisał swoje problemy z komponentami GXT oraz problematycznym MVC stworzonym przez autorów tejże biblioteki
  • W kwietniu 2009 pojawiło się pierwsze zestawienie implementacji MVC na blogu Supply Chain Technology
  • W maju 2009 na tym samym blogu pojawiła się aktualizacja z nowymi pozycjami.
  • Również w maju 2009 odbyła się konferencja Google IO na której temat developmentu GWT był szeroko i dokładnie omówiony.

Zacząłem nieśmiało, bo od stworzenia “szyny” którą mogły by się komunikować różne komponenty. Miała ona na celu zmniejszenie ilości bezpośrednich powiązań między elementami aplikacji. Pomogło, ale to nie było jeszcze to, co uporządkowało aplikację.

Drugie podejście mimo obaw wyniesionych z pierwszego linku padło na lightweight MVC z biblioteki GXT. Udało mi się stworzyć działającą aplikację, jednakże brak jasnego podziału co, kto i jak ma robić strasznie mi doskwierał. Problematyczna okazała się również próba stworzenia hierarchii kontrolerów, a zrobienie aplikacji od zera sprowadzało się tak na prawdę do skopiowania i przerobienia przykładu z Mail App. Podobnie jak Matt nigdy też nie wyłapałem różnicy między metodami Dispatcher.dispatch() oraz Dispatcher.forwardEvent().

Trzecie podejście do MVC zakrawało już szaleństwem. Po przejrzeniu dokumentacji GWTruts stwierdziłem, że zapowiada się ciekawie. Odseparowany widok i kontroler, API przypominające nieco Spring MVC, nieco XML do okraszenia całości wstrzykiwaniem zależności. Wszystko to jednak na nic, gdyż całość opiera się na mapowaniu adresów z przeglądarki do kontrolerów. Krzywe koniec końców okazało się też przekazywanie map z argumentami i w dalszym ciągu brak jakichkolwiek idei na zorganizowanie wszystkiego. A zapomniałbym – jeśli chcecie walidacji to musicie pogodzić się z tym że 1 kontroler to 1 klasa do sprawdzania danych. Szkoda że tego nie można “wstrzyknąć”.

Dobra, skoro nie GWTruts, nie GXT, i nie Event Bus to co? Krótki przegląd GWT-MVC skończył się odrzuceniem szkieletu. Skąd niby kontroler ma zajmować się tym gdzie ma wylądować widok? A tak właśnie się dzieje w tym szkielecie ponieważ kontroler wywołuje DOMPlacera by gdzieś umieścić widok. Jak by tych fanaberii było mało doszedł jeszcze interfejs Maskable który ma przykrywać elementy w trakcie renderowania. Dodajmy do tego przykłady które się sprowadzały do przycisków +2, -2 i inputa. Pytanie – co to ma do klasycznego MVC?

Tym oto sposobem dotarłem do ostatniego projektu, który mi zaimponował rozmiarem dokumentacji, spójną koncepcją i masą ograniczeń – Pure MVC. Projekt, który pierwotnie miał sporo do czynienia z Flashem, a który dzięki swojemu porządkowi został przepisany również na inne języki – min. PHP, Javę. Wśród portów nie zabrakło również wersji dla GWT. Nie muszę pisać jak bardzo mnie to ucieszyło, prawda? :-)
Całkiem duży przykład obrazuje powiązania pomiędzy komponentami oraz to jak powinny się komunikować:
Employee Admin Demo

Uzbrojony w ten zakres informacji stworzyłem pierwszą przykładową aplikację z ekranem logowania oraz jedną tabelką. Stopniowo go rozbudowując dotarłem do momentu w którym moja aplikacja w końcu przestała się kręcić wokół tego “które MVC” wybrać i zaczęła nabierać funkcjonalności biznesowej. Po długich bojach i masie straconego czasu, odradzam wszystkie inne implementacje Model View Controller dla GWT. Pure MVC jest po prostu najlepsze. :-)

 

2 replies


  1. Witam

    Czy zastanawiałeś się może nad zastosowaniem MVP. Na konferencji google i/o to właśnie podejście było sugerowane. Powiem szczerze że w naszej aplikacji od zawsze mieliśmy problemy z MVC, korzystaliśmy z implementacji zawartej w GXT. Jeśli chodzi o implementację MVC w GXT to powiem szczerze pozostawia ona wiele do życzenia. Dlatego też z uwagi na te problemy cały czas zastanawialiśmy jak lepiej rozwiązać problemy z którymi się borykaliśmy. Dopiero po przejrzeniu materiałów z Google I/O z maja, uznaliśmy że to jest kierunek w którym będziemy podążać, oczywiście musieliśmy przepisać dużą część aplikacji. Postanowiliśmy użyć gwt-presenter i gwt-dispatch, wiązało się to z dużą ilością pracy ale z perspektywy czasu mogę powiedzieć że się opłacało. Zgodnie z zaleceniami google zaczęliśmy używać bardzo intensywnie gin po stronie klienta i guice po stronie serwera. Po tych zmianach mogę śmiało powiedzieć że jednak warto było. MVP jest bardziej przejrzysty i oczywisty.

    A gin, no cóż raz zaczniesz używasz i już nie pamiętasz jak to było bez tego.

    Pozdrawiam
    Marcin Misiewicz


  2. Hej Misiek,
    Oczywiście, że zastanawiałem się nad MVP, ale brak konkretnych przykładów skutecznie mnie zniechęcił. Powiem Ci szczerze, że taki sam efekt uzyskałem w Pure MVC, ponieważ widok jako taki jest obsługiwany przez mediatora, który ma referencję do kontrolek. Z kolei widok może komunikować się tylko z mediatorem – czyli MVP. Dodatkowo w Pure MVC są wyodrębnione interfejsy IProxy oraz ICommand, które można wykorzystać – Proxy jako wrappery na serwisy RPC/JSON a Command do zaszycia wspólnej logiki.
    Jeśli idzie o gwt-dispatch i gwt-presenter. Po stronie serwera używam Spring MVC a komunikacja odbywa się przy pomocy JSON. Po stronie serwera GWT oferuje “wielkie nic”, stąd też wolałem skorzystać ze sprawdzonego narzędzia. :)
    Swoją narzędzia które używam można pobrać z SVN: Code-House GWT Tools bądź przejrzeć na Fisheye.
    W skład projektu wchodzą komponenty:
    – GXT Adapter – przerzuca POJO do rekordów GXT oraz z powrotem
    – JSON – generuje parsery JSON na bazie POJO
    – Rest Spring – generator proxy na bazie adnotacji @RequestMapping itp ze Springa.
    – Velocity – abstrakcyjny generator zbudowany na bazie Velocity

    Po nowym roku powinien być pierwszy release. :)

Leave a reply