[JAVA] JDBC, GUI, HashMap

[Rvanlaak]

Ik heb een GUI met een JList waarin ik op dit moment gebruikersnamen (voornaam, evt tussenvoegsel, achternaam) neerzet door middel van een JDBC koppeling en SQL. Het is ook de bedoeling dat ik die gebruikers kan wijzigen en verwijderen. Het probleem is dat gebruikersnamen ook dubbel kunnen zijn .(meerdere Jan Jansens ) Ik dacht dus: dan pak ik een HashMap om daarin als key het sofinr te zetten en als waarde de naam.

Als ik een gebruiker wil wijzigen staat in de JList de voornaam, (tussenvoegsel), achternaam. Hoe krijg ik het voor elkaar om van een gebruiker uit de JList weer het sofinr dat in de HashMap staat terug te krijgen? Hier is het probleem bij dat in de JList meerdere dezelfde waardes kunnen staan...

[Rvanlaak]

Misschien ter overige informatie:

De sofinrs die ik in de hashmap wil zetten zijn uniek. Want de key moet tog uniek zijn in een hashmap?

[momania]

Rvanlaak schreef op maandag 24 april 2006 @ 11:22:
De sofinrs die ik in de hashmap wil zetten zijn uniek. Want de key moet tog uniek zijn in een hashmap?

De hashCode() method van de objecten die je als key gebruikt uniek zijn.

Verder moet je denk ik zelf je model maken voor je list, zodat je daarin gewoon de gehele gebruiker kwijt kan ipv alleen maar een representatieve String

[Rvanlaak]

Eerst stonden in de JList ook de sofinrs, maar we vonden dit niet representatief. Als je namelijk de sofinrs zou hebben zou er nu geen probleem zijn, maar op deze manier is het zoeken, wijzigen en verwijderen wel gebruiksvriendelijker.

Zou de oplossing dus zijn om in de JList toch de sofinrs toe te voegen, of is er een andere manier?
Betekent deze oplossing dan dus ook dat ik geen HashMap meer nodig heb omdat een String[] genoeg is.

[matthijsln]

Rvanlaak schreef op maandag 24 april 2006 @ 11:38:
Zou de oplossing dus zijn om in de JList toch de sofinrs toe te voegen, of is er een andere manier?
Betekent deze oplossing dan dus ook dat ik geen HashMap meer nodig heb omdat een String[] genoeg is.

De index van een item in de JList is natuurlijk wel uniek. Zorg er dus voor dat je voor elke index weet wat het sofinr is.

Maak zoals momania zegt een eigen ListModel, daar kan je dat mooi in kwijt. Niet alleen kan je bijhouden op welke index welk sofinr staat, maar het mooiste is natuurlijk als je een lijst hebt met referenties naar Persoon objecten waarin naast sofinr, naam alle andere gegevens staan die je van een persoon nodig hebt.

Je moet dus helemaal geen (Hash)Map gebruiken in deze situatie.

[sig69]

Als ik jou was, zou ik een ListModel gebruiken waar je (zoals momania zegt) gebruiker-objecten in zet. Hoe je JList die gebruikers laat zien kan je volledig zelf bepalen.

[matthijsln]

momania schreef op maandag 24 april 2006 @ 11:27:
[...]
De hashCode() method van de objecten die je als key gebruikt uniek zijn.

Dat is helemaal geen vereiste hoor, je kan prima een HashMap hebben met daarin verschillende objecten (als in equals()) die allemaal dezelfde hashcode hebben. Het is welzo dat voor de performance van een hashmap het bevorderlijk is wanneer verschillende objecten verchillende hashcodes hebben, maar de uiteindelijke gelijkheid wordt door equals() bepaald.

[Kwistnix]

Leef je uit en schrijf een eigen implementatie van ListModel voor jouw specifieke eisen.


Edit:

Nu ga ik een cursus "lees het topic door voodat je post" volgen. *zwaai*

[ Voor 34% gewijzigd door Kwistnix op 24-04-2006 12:11 ]

[Rvanlaak]

1. Het nadeel van de hashmap is dan toch dat ik hiermee niet de mogelijkheid heb om er meerdere "Jan Jansens" in te zetten? En dan van een van die Jans het sofinr terug te krijgen.
   De JList houdt toch niet van zijn eigen inhoud ook de sofinrs bij in mijn geval?
2. Kun je bij een ListModel ook alleen de voornaam, (tussenvoegsel), achternaam tonen in de JList, en dan van diezelfde waarde er weer het sofinr uithalen? Dit zou dan namelijk mijn oplossing zijn omdat ik met dat sofinr weer in de database in een ander frame diezelfde klant moet kunnen wijzigen.

[coenbijlsma]

Volgens mij kun je toch ook gewoon een object in een JList stoppen? Dan kun je de pointer weer opzoeken in de HashMap, alleen moet je er dan wel telkens helemaal doorheen...

[momania]

Rvanlaak schreef op maandag 24 april 2006 @ 12:11:

1. Het nadeel van de hashmap is dan toch dat ik hiermee niet de mogelijkheid heb om er meerdere "Jan Jansens" in te zetten? En dan van een van die Jans het sofinr terug te krijgen.
   De JList houdt toch niet van zijn eigen inhoud ook de sofinrs bij in mijn geval?
2. Kun je bij een ListModel ook alleen de voornaam, (tussenvoegsel), achternaam tonen in de JList, en dan van diezelfde waarde er weer het sofinr uithalen? Dit zou dan namelijk mijn oplossing zijn omdat ik met dat sofinr weer in de database in een ander frame diezelfde klant moet kunnen wijzigen.

Kijk eens naar de javadocs van JList: http://java.sun.com/j2se/...pi/javax/swing/JList.html

Daar staan goede voorbeelden in, voor wat jij wilt. Je kan in je model dan gewoon je persoon objecten kwijt en met een ListCellRenderer imlpementatie zelf bepalen wat je van die persoon wilt laten zien in je GUI. In je model blijft het dan gewoon je volledige persoon object en hoef je dus ook niets meer moeilijk op te gaan zoeken

[Robtimus]

Waarom een eigen ListModel schrijven? ListModel ondersteunt Objects - de toString method wordt gebruikt voor het afbeelden in de GUI. Gebruik gewoon DefaultListModel en je bent klaar.
In je JList zet je dus je personen zelf, waarbij toString alleen de naam returned.

[Verwijderd]

Ik heb ongeveer hetzelfde ook al is moeten programmeren. Maak het jezelf echt niet moeilijk, gewoon objecten in die JList knallen. Ik geloof dat je gewoon moet zorgen dat ze serializable zijn.
Het is al een tijdje geleden, maar als het echt nodig is, zoek ik het wel even op hoe ik het juist gedaan heb. Mail me dan even.
Het zou trouwens maar erg zijn als iederen die iets in een JList wilt zetten die aanklikbaar is, die hele zever met die hashmaps moet gaan doen. Je moet dan toch altijd aan het object aankunnen?!

[Confusion]

IceManX schreef op maandag 24 april 2006 @ 12:29:
Waarom een eigen ListModel schrijven? ListModel ondersteunt Objects - de toString method wordt gebruikt voor het afbeelden in de GUI.

Maar het is niet echt netjes om de toString() te overriden omdat die toevallig in een GUI wordt afgebeeld. De toString() moet een zinvolle representatie van het object zijn en IMHO is alleen het sofinr. dat in dit geval niet.

[Robtimus]

Nee, maar in de JList moeten voornaam, evt tussenvoegsel en achternaam staan. Voor een object "Persoon" vind ik dat nog wel redelijk representatief

Maar een nieuwe cell renderer is idd beter.

[prototype]

matthijsln schreef op maandag 24 april 2006 @ 11:57:
[...]


Dat is helemaal geen vereiste hoor, je kan prima een HashMap hebben met daarin verschillende objecten (als in equals()) die allemaal dezelfde hashcode hebben. Het is welzo dat voor de performance van een hashmap het bevorderlijk is wanneer verschillende objecten verchillende hashcodes hebben, maar de uiteindelijke gelijkheid wordt door equals() bepaald.

Even als aanvulling De HashMap werkt grofweg hetzelfde als een HashTable, op synchronisatie en null waarden na, maar dat terzijde. Dit komt er op neer dat de HashMap met zogenaamde emmers werkt, die iirc bepaald worden adhv de hashCode van een Object (die je dus kan overriden). Anders gezegd, emmers specifiek voor een bepaalde hashCode. Wanneer je dus twee objecten hebt met dezelfde hashcode, en er dus een hashcollission optreedt, dan komen deze in dezelfde emmer terecht. Het gevolg is nu dat je een lineaire zoektijd hebt voor die emmer voor die objecten. Dat wordt dus verstaan onder nadelig voor de zoektijd.

[Janoz]

imho zou een toString functie een duidelijke representatie van het object weer moeten geven. Voor mij betekent dat oa dat wanneer objecten niet gelijk aan elkaar zijn, ze ook niet hetzelfde resultaat uit hun toString laten komen. Dat is echter vooral persoonlijke voorkeur.

[matthijsln]

prototype schreef op maandag 24 april 2006 @ 21:21:
[...]
Even als aanvulling De HashMap werkt grofweg hetzelfde als een HashTable, op synchronisatie en null waarden na, maar dat terzijde. Dit komt er op neer dat de HashMap met zogenaamde emmers werkt, die iirc bepaald worden adhv de hashCode van een Object (die je dus kan overriden). Anders gezegd, emmers specifiek voor een bepaalde hashCode. Wanneer je dus twee objecten hebt met dezelfde hashcode, en er dus een hashcollission optreedt, dan komen deze in dezelfde emmer terecht. Het gevolg is nu dat je een lineaire zoektijd hebt voor die emmer voor die objecten. Dat wordt dus verstaan onder nadelig voor de zoektijd.

Inderdaad werkt dat op zo'n soort manier. Btw, ik was nog vergeten te vermelden dat bij een HashMap dit opgaat voor de keys en niet voor de gekeyde objecten (anders heb je een HashSet).

[Robtimus]

Let er trouwens op dat, als je hash maps / sets gebruikt, de hashCode() waarde van de keys / waarden niet mag veranderen, anders kun je het object niet meer terugvinden. Het object blijft nml in de bucket met hashCode() == X zitten terwijl de hash code opeens Y is.

Gebruik dus immutable objecten zoals strings, of zorg er zelf voor dat de waarden niet veranderen.

TreeMap / TreeSet kent overigens hetzelfde probleem.