🚀 go-pugleaf

> 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. 

W dniu 11.06.2012 07:34, William Bonawentura pisze:
>> 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.

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

> 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 :).

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 :).
>

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

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

> 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ą. 

W dniu 19.06.2012 07:43, William Bonawentura pisze:
>> 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ą.

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