[GWT] Początek

[Lukasz Lenart]

Po ciężkich bojach udało mi się zestawić projekt na bazie Maven 2 z
obsługą GWT. Projekt jest tutaj [1] można go sobie sklonować jeśli ma
się Mercuriala. Musiałem czasowo wyłączyć wsparcie dla JDO - goal
enhance powodował konflikt z gwt:compile - ktoś wie jak to rozwiązać?

Kolejnym krokiem jest pisanie kodu - muszę tylko nakreślić jak ma
wyglądać ta aplikacja i hajda...

[1] http://code.google.com/p/gruuf-done/

Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/
Kapituła Javarsovia 2010
http://javarsovia.pl

[Michał Karolik]

ok pytania może głupie ale.. po to jest grupa by się uczyć :):

1. Dociągnałem sobie kod w nb, podpiąłem sobie tortoisehg w netbeansie (rozumiem, że jest to poprostu klient mercuriala). Testowo zacommitowalem w klasie linie z komentarzem // - czemu nie widzę tej zmiany przeglądając kod na http://code.google.com/p/gruuf-done/source/browse/src/main/java/com/gruuf/done/client/Application.java ?

2. "Projekt jest tutaj [1] można go sobie sklonować jeśli ma się Mercuriala" - chodzi poprostu o checkout na swój dysk?

3. To 1sza wersja projektu która się ogólnie nie buduje czy tylko u mnie? Bo nie wiem czy mam ręcznie wrzucać jakieś biblioteki do swojego repozytorium -
"'net.kindleit:maven-gae-plugin' not found in repository: Unable to download the artifact from any repository"

[Radosław Szmit]

W dniu 23 lutego 2010 17:58 użytkownik Lukasz Lenart <lukasz...@googlemail.com> napisał:

Po ciężkich bojach udało mi się zestawić projekt na bazie Maven 2 z
obsługą GWT.

To będzie czyste GWT czy planujesz dodanie Ext GWT lub Smart GWT? ;> 

Projekt jest tutaj [1] można go sobie sklonować jeśli ma
się Mercuriala.

Łukaszu a nie lepiej Mercuriala zamienić na Git'a? Na pewno nie jest gorszy (tak żeby świętej wojny nie wywołać :D) a masz lepsze wsparcie w IntelliJ idea ;)

W dniu 23 lutego 2010 21:10 użytkownik Michał Karolik <freakm...@gmail.com> napisał:

1. Dociągnałem sobie kod w nb, podpiąłem sobie tortoisehg w netbeansie (rozumiem, że jest to poprostu klient mercuriala). Testowo zacommitowalem w klasie linie z komentarzem // - czemu nie widzę tej zmiany przeglądając kod na http://code.google.com/p/gruuf-done/source/browse/src/main/java/com/gruuf/done/client/Application.java ?

Bo mercurial to DVCS i commit poszedł do Twojego lokalnego repozytorium ;)

--
Pozdrawiam serdecznie
Radosław Szmit

[Lukasz Lenart]

W dniu 23 lutego 2010 21:10 użytkownik Michał Karolik
<freakm...@gmail.com> napisał:

> ok pytania może głupie ale.. po to jest grupa by się uczyć :):
>
> 1. Dociągnałem sobie kod w nb, podpiąłem sobie tortoisehg w netbeansie
> (rozumiem, że jest to poprostu klient mercuriala). Testowo zacommitowalem w
> klasie linie z komentarzem // - czemu nie widzę tej zmiany przeglądając kod
> na
> http://code.google.com/p/gruuf-done/source/browse/src/main/java/com/gruuf/done/client/Application.java
> ?

Mercurial (hg) to rozproszone repo i to jest tak, że jak robisz comit
to robisz go do swojego lokalnego repo, dopiero jak zrobisz hg push to
wypchniesz swoje zmiany do repo. Możesz zrobić też pull i ściągnąć
zmiany z repo i nie koniecznie centralnego ale od kolegi ;-)

> 2. "Projekt jest tutaj [1] można go sobie sklonować jeśli ma się Mercuriala"
> - chodzi poprostu o checkout na swój dysk?

Tak, tylko że klonujesz całe repo i masz je lokalnie i to do niego idą comity

> 3. To 1sza wersja projektu która się ogólnie nie buduje czy tylko u mnie? Bo
> nie wiem czy mam ręcznie wrzucać jakieś biblioteki do swojego repozytorium -
> "'net.kindleit:maven-gae-plugin' not found in repository: Unable to download
> the artifact from any repository"

Odkomentuj sobie wpisy w pom.xml dotyczące repo

[Lukasz Lenart]

W dniu 23 lutego 2010 22:36 użytkownik Radosław Szmit
<radosl...@gmail.com> napisał:

> To będzie czyste GWT czy planujesz dodanie Ext GWT lub Smart GWT? ;>

Na początek czyste GWT, tak złapać podstawy a następnie będzie można
dokładać kolejne wodotryski :D

> Łukaszu a nie lepiej Mercuriala zamienić na Git'a? Na pewno nie jest gorszy
> (tak żeby świętej wojny nie wywołać :D) a masz lepsze wsparcie w IntelliJ
> idea ;)

Może by i było lepiej, ale Google Code obsługuje Mercuriala i SVN.
Mogłem wybrać GitHub ale gdzieś czytałem, że jednak Mercurial jest
lepszy ;-)
A co do wsparcia to nie widzę na razie problemów z IDEĄ

[Lukasz Lenart]

A i żeby uruchomić projekt trzeba wykonać:
mvn gwt:run

[Lukasz Lenart]

Trochę specyfikacji ;-)
http://code.google.com/p/gruuf-done/wiki/UkladOkna

[Lukasz Lenart]

Ktoś wie jak należy ustawić .hgignore? Stworzyłem w głównym katalogu
projektu i dodałem wpisy, jednak wciąż Mercurial pokazuje mi te pliki
w statusie :P

[Wojciech Erbetowski]

No ja wiem, dokładnie tak jak zrobiłeś.

HG ma prawa do pliku? Nie przestawiłeś w .hg/hgrc na inny plik?

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "Warszawa Java User Group (Warszawa JUG)".

Aby zamieszczać posty w tej grupie, wyślij e-mail na adres warsza...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres warszawa-jug...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/warszawa-jug?hl=pl.

[Wojciech Erbetowski]

Pokaż co jest w pliku .hgignore, może niewłaściwy format...

[Lukasz Lenart]

W dniu 24 lutego 2010 11:50 użytkownik Wojciech Erbetowski
<wojt...@gmail.com> napisał:

> Pokaż co jest w pliku .hgignore, może niewłaściwy format...

http://code.google.com/p/gruuf-done/source/browse/.hgignore

[Wojciech Erbetowski]

Nie może być tabulatorów przed ścieżkami :)

Każdy pattern zacznij od poczatku linii.

[Lukasz Lenart]

W dniu 24 lutego 2010 11:57 użytkownik Wojciech Erbetowski
<wojt...@gmail.com> napisał:

> Nie może być tabulatorów przed ścieżkami :)
> Każdy pattern zacznij od poczatku linii.

Właśnie sam do tego doszedłem :P

[Jacek Laskowski]

2010/2/24 Lukasz Lenart <lukasz...@googlemail.com>:

> W dniu 24 lutego 2010 11:57 użytkownik Wojciech Erbetowski
> <wojt...@gmail.com> napisał:
>> Nie może być tabulatorów przed ścieżkami :)
>> Każdy pattern zacznij od poczatku linii.
>
> Właśnie sam do tego doszedłem :P

Przyzwyczajenia z pythona czy make? :)

Nie uwierzysz, ale pytałem o hgignore 2 dni temu na twitterze
i...dostałem odpowiedź od Wojtka (buzz) i pietia i Al Gonzalez
(twitter). Nie mogłem uwierzyć, jak szybko nadeszła odpowiedź i to
wręcz od nieznanej mi osoby (!)

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://jaceklaskowski.pl
Kapituła Javarsovia 2010 - http://javarsovia.pl

[Lukasz Lenart]

Dzisiaj trochę powalczyłem i można powiedzieć, że aplikacja prawie działa :D
Zaczyna przypominać jakąś aplikację-potworka pisaną w Struts 1 ale to
się poprawi w miarę rozwoju ;-)

Pytanie do doświadczonych (prze życie ;-) kolegów:
utworzyłem klasę SimpleTask i umieściłem ją w pakiecie
com.gruuf.done.model jednak powodowało to problemy. Po przeniesieniu
do com.gruuf.done.client zaczęło działać - czyli tam gdzie jest klasa
entry-point. Czy można jakoś ustawić GWT aby wczytywało klasy z innego
pakietu? Trzeba coś dodać do *.gwt.xml albo utworzyć nowy *.gwt.xml?

Przypominam projekt jest tutaj -> http://code.google.com/p/gruuf-done/

[Adam Winciorek]

W dniu 24 lutego 2010 18:10 użytkownik Lukasz Lenart <lukasz...@googlemail.com> napisał:

[...]

Pytanie do doświadczonych (prze życie ;-) kolegów:
utworzyłem klasę SimpleTask i umieściłem ją w pakiecie
com.gruuf.done.model jednak powodowało to problemy. Po przeniesieniu
do com.gruuf.done.client zaczęło działać - czyli tam gdzie jest klasa
entry-point. Czy można jakoś ustawić GWT aby wczytywało klasy z innego
pakietu? Trzeba coś dodać do *.gwt.xml albo utworzyć nowy *.gwt.xml?

Przypominam projekt jest tutaj -> http://code.google.com/p/gruuf-done/

Domyślnie powinieneś móc widzieć wszystkie klasy które masz w pakiecie 'client' oraz w podpakietach pakietu 'client'.
Możesz dodać wpisy:
<entry-point class="xxx.yyy.zzz.client.Nazwa_Modulu" />
    <source path="client" />
w Nazwa_Modulu.gwt.xml ale myślę ze te wartości i tak są domyślne.

Poza tym możesz używać klas z zewnętrznych jarów (np. swoja domenę trzymasz w domain.jar). Używam mavena wiec posłużę się jego nazewnictwem. Chodzi wiec o to ze domain.jar masz jako dependency w pom.xml.

domain.jar to wynik mvn package na jakimś tam tymże module maven-owym (domenowym) w Twoim projekcie. Ważne jest aby w pliku
Nazwa_Modulu.gwt.xml modulu UI (z pakietem 'client') byl wpis:
<inherits name="xxx.yyy.zzz.ModulDomain" />

zaś w samym module domenowym w pakiecie src/main/resources/xxx/yyy/zzz/ miec plik ModulDomain.gwt.xml. W tym pliku możesz mieć swoja droga jakieś wpisy np:
<source path="domain/model"/>
aby zawęzić zbiór klas, które maja być używane i kompilowane przez GWT (nie wszystkie klasy się da przez -> tylko te z JRE Emulation Reference.

Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/

Kapituła Javarsovia 2010
http://javarsovia.pl

Pozdrawiam,
Adam 

[Paweł Stawicki]

Pamiętaj, że GWT "kompiluje" kod Javy do Javascriptu. Domyślnie właśnie wszystko to co jest w pakiecie client (i podpakietach) jest kompilowane do javascriptu i dostępne w kodzie klienckim. Oczywiście mamy tam pewne ograniczenia, możemy używać tylko "części" Javy, bo nie wszystko GWT potrafi na JS przełożyć.

Czy można skonfigurować inny pakiet niż client? Pewnie tak, chociaż nie wydaje mi się to dobrym pomysłem. Nie lepiej trzymać się standardu?

Jeśli korzystasz z innych bibliotek, one też muszą mieć część kliencką w pakiecie client, a w ich jarach muszą byś ŹRÓDŁA (pliki .java). Bo właśnie źródła javy GWT przerabia na JS, nie bytecode. Oczywiście wymóg ten (żeby źródła były w classpath) dotyczy nie całej biblioteki, a tylko części klienckiej, czyli tego co w "client" i poniżej.

Pozdrawiam

--
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl

2010/2/24 Lukasz Lenart <lukasz...@googlemail.com>

[Lukasz Lenart]

Dzięki za odpowiedzi, tak się domyślałem, że to właśnie ta kliencka
strona GWT ;-)

Mam jeszcze jedną wątpliwość - czy nie lepiej rozdzielić część
kliencką od części serwerowej w Mavenie? Mieć moduł z klientem i moduł
serwerowy, ale tak aby razem tworzyły jednego wara? Jest to możliwe?

Patrzyłem na SmartGWT oraz ExtGWT - całkiem fajne!

[Paweł Stawicki]

Ja bym wolał mieć w jednym projekcie. Domyślam się (wybacz, nie mam czasu spojrzeć na kod) że nie korzystałeś jeszcze z wywołań RPC? Jak z nich korzystasz, to musisz mieć interfejs, jego wersją asynchroniczną, implementację, i z klienta odwoływać się do asynchronicznego interfejsu.

No można rozdzielić, mieć w kliencie interfejsy, a w części serwerowej implementację, ale wtedy część serwerowa robi się zależna od klienta - nie śmierdzi Ci to? ;) Można też wydzielić te interfejsy do trzeciego projektu, ale wydaje mi się że to przerost formy nad treścią.

Uprzedzam pytanie: czy można mieć interfejsy w części serwerowej?

Można, ale one muszą być w pakiecie "client", a jak go zrobisz w części serwerowej to już nie będzie tak całkiem serwerowa ;) Chociaż jak się uprzesz na ten rozdział to to wydaje mi się najlepszym rozwiązaniem. Ale ja bym się nie upierał ;)

Pozdrawiam

--
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl

2010/2/25 Lukasz Lenart <lukasz...@googlemail.com>

[Lukasz Lenart]

W dniu 25 lutego 2010 14:07 użytkownik Paweł Stawicki
<pawels...@gmail.com> napisał:

> Ja bym wolał mieć w jednym projekcie. Domyślam się (wybacz, nie mam czasu
> spojrzeć na kod) że nie korzystałeś jeszcze z wywołań RPC? Jak z nich
> korzystasz, to musisz mieć interfejs, jego wersją asynchroniczną,
> implementację, i z klienta odwoływać się do asynchronicznego interfejsu.
> No można rozdzielić, mieć w kliencie interfejsy, a w części serwerowej
> implementację, ale wtedy część serwerowa robi się zależna od klienta - nie
> śmierdzi Ci to? ;) Można też wydzielić te interfejsy do trzeciego projektu,
> ale wydaje mi się że to przerost formy nad treścią.
> Uprzedzam pytanie: czy można mieć interfejsy w części serwerowej?
> Można, ale one muszą być w pakiecie "client", a jak go zrobisz w części
> serwerowej to już nie będzie tak całkiem serwerowa ;) Chociaż jak się
> uprzesz na ten rozdział to to wydaje mi się najlepszym rozwiązaniem. Ale ja
> bym się nie upierał ;)

Hmmm... ciekawe, czyli wszystko w jednym module, kod klienta (UI),
interfejsy i ich implementację serwerową - ok do przyjęcia jak używam
GWT-RPC, a co w przypadku, gdy część serwerowa to nie GWT-RPC tylko
np. Struts 2 i komunikacja za pomocą JSONa?

[Paweł Stawicki]

2010/2/25 Lukasz Lenart <lukasz...@googlemail.com>

W dniu 25 lutego 2010 14:07 użytkownik Paweł Stawicki
<pawels...@gmail.com> napisał:

> Ja bym wolał mieć w jednym projekcie. Domyślam się (wybacz, nie mam czasu
> spojrzeć na kod) że nie korzystałeś jeszcze z wywołań RPC? Jak z nich
> korzystasz, to musisz mieć interfejs, jego wersją asynchroniczną,
> implementację, i z klienta odwoływać się do asynchronicznego interfejsu.
> No można rozdzielić, mieć w kliencie interfejsy, a w części serwerowej
> implementację, ale wtedy część serwerowa robi się zależna od klienta - nie
> śmierdzi Ci to? ;) Można też wydzielić te interfejsy do trzeciego projektu,
> ale wydaje mi się że to przerost formy nad treścią.
> Uprzedzam pytanie: czy można mieć interfejsy w części serwerowej?
> Można, ale one muszą być w pakiecie "client", a jak go zrobisz w części
> serwerowej to już nie będzie tak całkiem serwerowa ;) Chociaż jak się
> uprzesz na ten rozdział to to wydaje mi się najlepszym rozwiązaniem. Ale ja
> bym się nie upierał ;)

Hmmm... ciekawe, czyli wszystko w jednym module

Niekoniecznie w jednym module. W projekcie nad którym pracuję używamy wielu modułów, ale ich podział jest podyktowany raczej funkcjonalnością, a nie rozdziałem klient <-> serwer.

 

, kod klienta (UI),
interfejsy i ich implementację serwerową - ok do przyjęcia jak używam
GWT-RPC, a co w przypadku, gdy część serwerowa to nie GWT-RPC tylko
np. Struts 2 i komunikacja za pomocą JSONa?

Jak nie używasz GWT-RPC, to nie masz problemu z tymi interfejsami (w pakiecie "client" w module serwerowym) o których pisałem. Jeśli w GWT programujesz tylko część kliencką, to spokojnie możesz sobie wydzielić to do osobnego projektu, bo nigdzie indziej pakietu "client" nie potrzebujesz.

[splatch]

Jeśli ktoś jest zainteresowany rozdzieleniem kodu klienta i serwera
zapraszam do lektury wiki Code-House:

http://inside.code-house.org/confluence/display/GWT/Setup+projektu+GWT
W tle Maven 2, GWT oraz Jetty.

Code-House uwalnia wiedzę zawartą na wiki. :-)

Pozdrawiam,
Łukasz Dywicki

On Feb 25, 2:23 pm, Paweł Stawicki <pawelstawi...@gmail.com> wrote:
> 2010/2/25 Lukasz Lenart <lukasz.len...@googlemail.com>

>
>
>
> > W dniu 25 lutego 2010 14:07 użytkownik Paweł Stawicki

> > <pawelstawi...@gmail.com> napisał:

[Lukasz Lenart]

W dniu 26 lutego 2010 14:30 użytkownik splatch
<lukasz....@gmail.com> napisał:

> Jeśli ktoś jest zainteresowany rozdzieleniem kodu klienta i serwera
> zapraszam do lektury wiki Code-House:
>
> http://inside.code-house.org/confluence/display/GWT/Setup+projektu+GWT
> W tle Maven 2, GWT oraz Jetty.

Super, że udostępniłeś ten wpis, ale brakuje w nim załączonego
webdefault.xml o którym wspominasz w treści.

[Lukasz Lenart]

Szukając "dobrego podejścia" do GWT natrafiłem na wpis [1] a tam
porównanie kilka MVC dla GWT. Rekomendowany jest Pure MVC [2], co o
tym myślicie, jest to dobre podejście czy może pozostać przy
standardowy MVP [3]?

[1] http://blog.code-house.org/2009/11/gwt-and-mvc-implementations/
[2] http://puremvc.org/
[3] http://code.google.com/intl/pl/webtoolkit/doc/latest/tutorial/mvp-architecture.html

[splatch]

Cześć Łukasz,

Jeśli idzie o webdefault to jego zawartość jest dostępna tutaj:
http://inside.code-house.org/confluence/pages/viewpageattachments.action?pageId=1900552
Treść z poprawkami:
http://inside.code-house.org/confluence/download/attachments/1900552/webdefault.xml

Co do zestawienia szkieletów MVC dla GWT - myślę że przez ostatnie pół
roku nieco się pozmieniało. Fakt z PureMVC porządek rzeczy został
zachowany, jakkolwiek przy drugiej aplikacji kolega (http://
michalmech.pl) zapiął MVP i też nie wygląda to źle. Praca z PureMVC i
z widokiem w stylu master-detail jest ogólnie prosta ale trzeba
samodzielnie koordynować zdarzenia. Co mam na myśli pisząc
koordynować? To, że trzeba zarejestrować odpowiednio listenera na dany
topic i je wysyłać z odpowiednim kluczem. Zdarzenia z określonego
widoku (master), nie są korelowane automatycznie z listenerami tego
widoku, mimo że Mediator jest observerem widoku musimy deklarować
zainteresowanie danym zdarzeniem.
Uciążliwe jest to, że w wielu miejscach pojawiają się nazwy eventów
(wykorzystywałem enumy bo zamiast if else if else można było zrobić
switch), co z biegiem czasu staje się trudne do ogarnięcia.

Pozdrawiam,
Łukasz

On Mar 4, 2:27 pm, Lukasz Lenart <lukasz.len...@googlemail.com> wrote:
> Szukając "dobrego podejścia" do GWT natrafiłem na wpis [1] a tam
> porównanie kilka MVC dla GWT. Rekomendowany jest Pure MVC [2], co o
> tym myślicie, jest to dobre podejście czy może pozostać przy
> standardowy MVP [3]?
>
> [1]http://blog.code-house.org/2009/11/gwt-and-mvc-implementations/
> [2]http://puremvc.org/

> [3]http://code.google.com/intl/pl/webtoolkit/doc/latest/tutorial/mvp-arc...
>
> Pozdrawiam
> --
> Łukaszhttp://www.lenart.org.pl/
> Kapituła Javarsovia 2010http://javarsovia.pl

[Lukasz Lenart]

W dniu 5 marca 2010 14:26 użytkownik splatch <lukasz....@gmail.com> napisał:
> Co do zestawienia szkieletów MVC dla GWT - myślę że przez ostatnie pół
> roku nieco się pozmieniało. Fakt z PureMVC porządek rzeczy został
> zachowany, jakkolwiek przy drugiej aplikacji kolega (http://
> michalmech.pl) zapiął MVP i też nie wygląda to źle. Praca z PureMVC i
> z widokiem w stylu master-detail jest ogólnie prosta ale trzeba
> samodzielnie koordynować zdarzenia. Co mam na myśli pisząc
> koordynować? To, że trzeba zarejestrować odpowiednio listenera na dany
> topic i je wysyłać z odpowiednim kluczem. Zdarzenia z określonego
> widoku (master), nie są korelowane automatycznie z listenerami tego
> widoku, mimo że Mediator jest observerem widoku musimy deklarować
> zainteresowanie danym zdarzeniem.
> Uciążliwe jest to, że w wielu miejscach pojawiają się nazwy eventów
> (wykorzystywałem enumy bo zamiast if else if else można było zrobić
> switch), co z biegiem czasu staje się trudne do ogarnięcia.

Czyli MVP na początek będzie git! ;-) Dzięki!

[Paweł Stawicki]

Też bym użył MVP. Zwłaszcza że to koncepcja Googla, więc będą ją wspierać w swoich rozwiązaniach.

--

Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl

2010/3/7 Lukasz Lenart <lukasz...@googlemail.com>