EXT-GWT BeanModelTag czy coś da się zautomatyzować :)?

J-23

unread,

Jun 9, 2012, 5:59:45 PM6/9/12

to

Witam,
Czy istnieją jakieś "ficzery" by budować klasy implementujące
BenModelTag z automatu?

Może jakieś info gdzie można by poczytać o tym.

Chodziło by mi o coś takiego że na podstawie zapytania SQL budować i
metadanych budować odpowiednią klasę

Bo co prawda można ją budować ręcznie nie ma z tym problemu ale było by
fajnie jakby jakiś automat to robił jak nie w całości to przynajmniej w
jakiejś części

Pozdrawiam

William Bonawentura

unread,

Jun 11, 2012, 1:34:32 AM6/11/12

to

> Czy istnieją jakieś "ficzery" by budować klasy implementujące BenModelTag
> z automatu?

Poczytaj o BeanModelMarker. Ale w Ext 3.0 wprowadzono nowe rozwiązanie - z
interfejsami dostępowymi (Property) opartymi o generyki, które jest
eleganckie i dużo mniej kłopotliwe niż BeanModel. Twoje pytanie sugeruje, że
raczej zaczynasz prace z Ext, więc wybór 3.0 jest chyba najlepszym
rozwiązaniem.

J-23

unread,

Jun 11, 2012, 11:51:21 AM6/11/12

to

W dniu 11.06.2012 07:34, William Bonawentura pisze:

Kiedys robilem pare rzeczy nawet udalo mi sie zbudować dość sporą
aplikację jeszcze na wersji 2.

Ale bez wątpienia fachowiec jeśli chodzi o GXT ze mnie marny :)

Co prawda przegrzebałem źródła z wersji trzeciej już wcześniej (Jeszcze
przed Twoją odp). Wygląda to niezle i czas podciągnąć swoją wiedzę pod
tą wersje. Tylko pytanie czy To o co pytałem na początku jest do
osiągnięcia czy też może jeszcze oczekuje czegoś co się zwyczajnie na
obecną chwile nie da lub jest mało opłacalne?

Pytam bo nie chce zmarnować czasu tylko po to by się okazało że się
zwyczajnie nie da

Pozdrawiam

William Bonawentura

unread,

Jun 12, 2012, 7:28:28 AM6/12/12

to

> tą wersje. Tylko pytanie czy To o co pytałem na początku jest do
> osiągnięcia czy też może jeszcze oczekuje czegoś co się zwyczajnie na
> obecną chwile nie da lub jest mało opłacalne?

Trudno odpowiedzieć na pytanie, czy można budować automatycznie BenModelTag,
skoro już ich w 3.0 nie ma :).

J-23

unread,

Jun 12, 2012, 12:31:38 PM6/12/12

to

W dniu 12.06.2012 13:28, William Bonawentura pisze:

Widzę że musze sobie zbudować jakąś prostą siatkę plus kilka komponentów
i spróbować zasady działania w wersji 3 (namacalnie :) ) wtędy
ewentualnie wróce do pytań. Tymczasem dzieki za info.

Pozdrawiam

J-23

unread,

Jun 18, 2012, 8:57:49 PM6/18/12

to

W dniu 12.06.2012 18:31, J-23 pisze:

> W dniu 12.06.2012 13:28, William Bonawentura pisze:
>>> tą wersje. Tylko pytanie czy To o co pytałem na początku jest do
>>> osiągnięcia czy też może jeszcze oczekuje czegoś co się zwyczajnie na
>>> obecną chwile nie da lub jest mało opłacalne?
>>
>> Trudno odpowiedzieć na pytanie, czy można budować automatycznie
>> BenModelTag, skoro już ich w 3.0 nie ma :).
>>
>

Bonawetura przeanalizowałem zasadę działania i już co nie co zaczynam
rozumieć ale meczy mnie jedna rzecz jak zbudować jakiś mechanizm który w
sposób uniwersalny będzie mi pomagał budować odpowiednie siatki i ich
obsługę. Przez sposób uniwersalny rozumiem to tak że trochę
zautomatyzuje ten proces

Znalazłem coś takiego
http://turbomanage.wordpress.com/2011/03/25/using-gwt-requestfactory-with-objectify/
wygląda obiecująco ale zastanawia mnie czy idę w dobrą stronę.

Tak żebyś zrozumiał o co mi chodzi to posłużę się przykładem:

Załóżmy że chcę zbudować (SQL Editor) okno gdzie u góry tego okna będę
pisał kwerendę sql a pod spodem będę miał jej wynik w gridzie. Czy jest
to do osiągnięcia w GXT? i czy lik który podałem prowadzi mnie w dobrym
kierunku

Pozdrawiam

William Bonawentura

unread,

Jun 19, 2012, 1:43:46 AM6/19/12

to

> Załóżmy że chcę zbudować (SQL Editor) okno gdzie u góry tego okna będę
> pisał kwerendę sql a pod spodem będę miał jej wynik w gridzie. Czy jest to
> do osiągnięcia w GXT? i czy lik który podałem prowadzi mnie w dobrym
> kierunku

To specyficzny przypadek. Podstawowe konstrukcje zakładają, że mamy ściśle
określony obiekt danych, który w swoich atrybutach ma dane dla kolumn. Ty po
każdym zapytaniu SQL będziesz miał inny typ wyniku więc i nie zaprojektujesz
klasy która go opisuje. Dlatego proponuję jako obiekt danych użyć zwykłej
mapy (a jako implementacji FastMap bo działa ona bezpośrednio przez Object
javascriptowy). Implementacji ValueProvider dla kolumn nie zrealizujesz
rzecz jasna generatorem z PropertyAccess, tylko napiszesz własną, czytającą
mapę. Budowę kolumn w gridzie i tak musisz zrobić dynamiczną.

J-23

unread,

Jun 19, 2012, 6:10:31 AM6/19/12

to

W dniu 19.06.2012 07:43, William Bonawentura pisze:

Dzięki za podpowiedz :)

Będę próbował największy orzech chyba będę miał do zgryzienia budując
własne rozwiązanie zamiast PropertyAccess. Tak mi się wydaje.

Pozdrawiam