[Java lista] JComboBox(hash)

[bognár attila]

szia,

>> szerintem érdemes lenne elolvasni egy swing tutorial és átnézni kicsit a 
>> swing API-t, ugyanis a swing gyakorlatilag MVC felépítésű, minden 
>> megjelenített elemnek van egy "Model" háttere, valamint egy "Renderer" 
>> foglalkozik a megjelenítéssel. Ja, és OO :-)
>>     
>
> Van még kiválasztás modell is, azt kihagytad :) (igaz comboboxnál pont 
> nincs ;)
>   

mármint a selection modelre gondolsz? de az már a view része alapvetően, 
MVC síkon annak nem sok szerepe van.


>> az összetettségből kifolyólag több lehetőség is van megvalósítani azt, 
>> amit akarsz:
>> - készítesz egy saját renderert
>> - amint egy másik kolléga írta a "bab" toString metódusát 
>> felüldefiniálod, esetleg az equals-t is.
>>
>> jelen esetben valószínűleg a második egyszerűbb.
>>     
>
> Tudnál esetleg mondani egy cimet, ahol valami leiras van, hogy pontosan 
> mely rutinokat is kellene átírni? Vagy egy példát, vagy valamit?
> (Az eredeti kérés is ez volt :) Nem vagyok túl gyakorlott javaban... :(
>   

az api doc-ban van példa a renderer testre szabására (ilyenre még nem 
volt szükségem), lásd ListCellRenderer interface (amit nem értek benne, 
az a JList paraméter, de kis utánajárással biztos meg lehetne fejteni)


>> ui: azért lássuk be, hogy egy hash alapú combobox nem feltétlenül lenne 
>> célravezető, hiszen fontos a sorrend, egy hash pedig ilyen apróságokkal 
>> nem foglalkozik.
>>     
>
> Ez mondjuk inkabb a hash megvalositas hianyossaga, hogy nincs sort... :)))
> De ha nem tetszik a hash, lehet felolem 2 vector vagy tömb vagy akármi, 
> lényeg hogy kulcs-érték párokkal dolgozzon.
>   

innentől kezdve az a kérdés, hogy mit tekintünk hash-nak. az én 
megközelítésem szerint a hash egy olyan doboz, amibe kulcs alapján 
beteszik valamit, majd ugyanazt visszakapom a kulcs alapján.
(például ruhatár: engem nem érdekel, hogy hova akasztja a kabátot, a 
lényeg, hogy a biléta alapján visszakapjam)


>> ha mégis ilyen kell, akkor kell egy saját 
>> ComboBoxModelt csinálni, ami biztosítja a funkcionalitást valamilyen 
>> módon. nem nehéz.
>>     
>
> Biztosan nem, ha már csináltál ilyet... ;)
>   

Két út van: megvalósítod a ComboBoxModel interface-t, vagy felül 
definiálod a DefaultComboBoxModelt. Annyira szerintem nem vészes dolog. 
+ rendelkezésre áll a java forrása, ha a DefaultComboBoxModelről kellene 
info.

A lényeg valahol ott van, hogy pl a DefaultComboBoxModelben pl felül 
kell definiálni az addElement metódust, mely két dolgot csinál: meghívja 
az ős metódust, és beregisztrálja az objektumodat egy belső hash-be. 
Hátramaradó feladatok: egy metódus, ami proxy-ként szerepel a hash felé 
(get, remove), valamint a remove*Element* metódusok felüldefiniálása az 
addElement-hez hasonlóan, azaz ne maradjon szemét a belső hash-ben.


>> hogy miért nem így van alapból? mert ez alapvetően nem 
>> OO és ez a megvalósítás gyengítené a rugalmasságot és a lehetőségek 
>> tárházát, esetleg rossz irányba vezetné el a tisztelt fejlesztők 
>> fantáziáját :-)
>>     
>
> Miert nem oo? Most is megadhatsz mondjuk vectort, az akkor nem oo?
> Egyébként meg azért lenne értelme, mert mint írtam is, pont az MVC miatt 
> szinte mindig kódokkal dolgozol, és megjelenítésnél jelennek csak meg az 
> értékek.  Nyugodtan bele rakhattak volna alapól egy ilyen modellt is, 
> attól nem sérülne se az oo, se a rugalmasság ;)
>   

A hash alapú megközelítés (jelen esetben) azért nem OO, mert az már egy 
konkrét objektum azonosítási megvalósítás, azaz nem objektumok alapján 
kezeled a listát, hanem valamilyen specifikus tulajdonság alapján. Mi 
van akkor, ha egy kulccsal (egy jellemzővel) nem is tudod azonosítani?

Ilyen megvalósítás is készülhetett volna: biztos, de én eddig nem igazán 
láttam hiányát ebben a formában, a dolog másik fele, hogy ilyen 
megközelítéssel valószínűleg nagyon sokféle megvalósítást bele kellett 
volna tenni, ami a java api-nak valószínűleg nem célja.

attila


--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20061214/74333076/attachment.html