Home > FLEX > Własny renderer dla DataGrid (FLEX)

Własny renderer dla DataGrid (FLEX)

Adobe FLEX posiada komponent do wyświetlania tabelek który nazywa się DataGrid. W komórce tabeli możemy wyświetlić tekst, tekst HTML lub inny prosty komponent. Mi jednak tego było mało. Postanowiłem więc napisać swój własny renderer dla komórek tabeli. Z początku wydawało mi się to proste: napiszę nową klasę dziedziczącą po DataGridItemRenderer i w niej upakuję logikę do wyświetlania mojej komórki tabeli. Niestety rzeczywistość okazała się niezwykle zagmatwana i zmusiła mnie do dokopania się do nieprzyzwoitych paskudztw ukrytych wewnątrz FLEX.

Nie mogłem zrobić klasy pochodnej z DataGridItemRenderer, gdyż tak klasa dziczy po UITextField czyli potrafi wyświetlać tekst. A ja potrzebowałem tekst i coś jeszcze. Spróbowałem więc pisać na płótnie Canvas. Okazało się, że Canvas prawie działa. Problemem były wartości, które poprzez interfejs IDataRenderer otrzymywała moja klasa: zamiast spodziewanego obiektu reprezentującego konkretną komórkę tabeli otrzymywałem obiekt reprezentujący cały wiersz. Zastanowiło mnie też dlaczego klasa Canvas – czyli obiekt reprezentujący płótno implementuje interfejs IDataRenderer – może Wy widzicie związek? Dla mnie to tak jak mercedes standardowo wyposażony w pieska kiwającego głową.

Analizując przykłady, odkryłem że klasa CheckBox powinna zachowywać się w tej materii właściwie, czyli gdy chciałem aby komórka tabeli była wyświetlana obiektem klasy CheckBox – to obiekt ten otrzymywał dane reprezentujące konkretną komórkę a nie cały wiersz. To mnie zastanowiło, dlaczego Canvas dostaje do wyświetlenia wiersz a CheckBox dostaje wartość komórki. Pomyślałem, że problem leży gdzieś w interfejsach. Pomyślałem sobie, że może DataGrid wpisując dane do komórek swojej tabeli sprawdza – czy klasa odpowiedzialna za wyświetlenie tej komórki implementuje wskazany interfejs – i w zależności od tego wysyła do nie odpowiednie dane. To by brzmiało rozsądnie. Niestety, debugger nie potwierdził moich przeczuć.

Zajrzałem więc do źródła CheckBox i oto co znalazłem. Jest tam sobie funkcja setter na pole data wymagana przez interfejs IDataRenderer. Oto ona:

W moim odczuciu, to nie wygląda jak zwykły setter. Dla mnie to wygląda jak na kod zepsutego projektu. Taka napisana funkcja zachowuje się w sposób nieprzewidywalny. W dodatku, po co ktoś projektował interfejs skoro większość klas FLEXa go odziedziczy?

Wracając do sprawy, aby napisać własną klasę służącą do wyświetlania komórek tabeli powinniśmy zaimplementować interfejsy: IDataRendererIDropInListItemRenderer. Aby dostać wartość wiersza potrzebny jest nam IDataRenderer, jednak ten interfejs implementują prawie wszystkie komponenty FLEXa. Aby dobrać się do wartości komórki, potrzebujemy IDropInListItemRenderer. Możemy do zrobić na przykład tak:

Martwię się o FLEX. To wspaniała technologia, która umożliwia tworzenie wspaniałych rzeczy. Jednak bałagan który w niej panuje może być dla tej niej zabójczy. Bałagan, o którym wie każdy programista, który programował w FLEX. Bałagan oczywiście zawsze towarzyszy pracy programistów, jednak w niektórych projektach jest czasami nie do zniesienia.

Categories: FLEX Tags:
  1. No comments yet.
  1. No trackbacks yet.

Subscribe without commenting