[Java]Objecten in JList

[maurad3r]

Ik werk op het moment met een JList die gebruik maakt van een DefaultListModel om objecten in op te sla, so far so good. De objecten in de JList worden allemaal gepresenteerd door een String, bv: 'beveiliging.Branche@b8'. Mijn vraag: is het mogelijk deze naam te veranderen, en zo ja: hoe!

Alvast bedankt.

[Gonadan]

Wat bedoel je precies met "ze worden gepresenteerd door een string"?

gebruikt je een toString methode? Want die moet je vaak zelf schrijven voor objecten.

edit: wat code zou ook handig zijn

[ Voor 19% gewijzigd door Gonadan op 23-03-2006 11:05 ]

[maurad3r]

Ik heb al geprobeerd een ToString() functie te maken: dat maakte geen enkel verschil.
Een stukje voorbeeldcode van wat ik nu ongeveeer heb.

code:

public class Product
{
    public int m_id;
    public String m_naam;

    // Constructor
    // Getters en Setters
}

public class TestApplet extends JApplet
{
    public DefaultListModel m_lmLijst;
    public JList m_lbLijst;

    public void init ( )
    {
        m_lmLijst = new DefaultListModel ( );
        m_lbLijst = new JList(m_lmLijst);

        m_lmLijst.addElement( new Product ( 10, "Testnaam" ) );
    }
}

[maurad3r]

Stomme ik dat ik ben: ToString moest dus toString zijn .
Ik ben zo gewend methodes met een hoofdletter te doen dat ik altijd vergeet dat de standaard Java klassen dat niet doen (waarom niet eigenlijk?).

Erg bedankt Gonadan!!

[bvp]

Maurad3r schreef op donderdag 23 maart 2006 @ 11:14:
Ik heb al geprobeerd een ToString() functie te maken: dat maakte geen enkel verschil.
Een stukje voorbeeldcode van wat ik nu ongeveeer heb.

[/code]

Geef es de toString() method die je gemaakt hebt?

Maurad3r schreef op donderdag 23 maart 2006 @ 11:17:
Stomme ik dat ik ben: ToString moest dus toString zijn .
Ik ben zo gewend methodes met een hoofdletter te doen dat ik altijd vergeet dat de standaard Java klassen dat niet doen (waarom niet eigenlijk?).

Erg bedankt Gonadan!!

Wen jezelf dan maar heel snel aan om methodes met een kleine letter te gaan schrijven!
Het is gewoon de conventie in Java om:
variablen: beginnen met kleine letter (volgend woord hoofdletter) ikBenLief
methoden: hetzelfde -> public void ikBenLief();
classes: hoofdletter beginnen, volgend woord ook hoofdletter -> public class IkBenLiever

kamelenStijl

Dit is gewoon zo afgeproken zodat je objecten, variablen etc. niet door elkaar haalt

[ Voor 57% gewijzigd door bvp op 23-03-2006 11:21 ]

[CyBoB]

JList pakt standaard de toString van je object om de items weer te geven. de "beveiliging.Branche@b8" tekst die je te zien krijgt is de default toString van Object en in dit geval het Branche object. Wat je dus zult doen is een toString functie moeten maken die de correcte tekst representatie terug geeft. iets als:

code:

public class Product
{
    public int m_id;
    public String m_naam;

    public String toString()
    {
        return this.m_naam;
    }
}

Als je dan een Product instantie aan je JList toevoegd dan zal er netjes de opgegeven naam getoond worden.


//edit
Moet sneller leren typen

[ Voor 7% gewijzigd door CyBoB op 23-03-2006 11:24 ]

[bvp]

CyBoB schreef op donderdag 23 maart 2006 @ 11:23:
JList pakt standaard de toString van je object om de items weer te geven. de "beveiliging.Branche@b8" tekst die je te zien krijgt is de default toString van Object en in dit geval het Branche object. Wat je dus zult doen is een toString functie moeten maken die de correcte tekst representatie terug geeft. iets als:

code:

public class Product
{
    public int m_id;
    public String m_naam;

    public String toString()
    {
        return this.m_naam;
    }
}

Als je dan een Product instantie aan je JList toevoegd dan zal er netjes de opgegeven naam getoond worden.


//edit
Moet sneller leren typen

Tja kan zo.
Kunt ook gewoon in de class Product een methode getName() definieren en die aan de JList toevoegen. String is immers ook een Object

Dan houd je je toString() method voor het uitprinten van het gehele object Product -> dus bijv id EN name.

[Gonadan]

Volgens mij heeft hij het al werkend, of ik moet het verkeerd begrepen hebben.

[maurad3r]

Gonadan schreef op donderdag 23 maart 2006 @ 11:28:
Volgens mij heeft hij het al werkend, of ik moet het verkeerd begrepen hebben.

Hehe.. helemaal correct!
Allemaal toch bedankt, ik ga mezelf maar eens aanleren methodes met kleine letters te beginnen.

[Gonadan]

Maar uiteindelijk probeerde je dus met een ToString() methode de toString() methode van de superclass te overrulen?

Dan maar de conventie volgen inderdaad

[JKVA]

Leer jezelf dan ook meteen aan dat in Java de Hungarian notatie niet gebruikt wordt. Zie link:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html, hoofdstuk 9: naming conventions.

Dat is de standaard en die wordt door vrijwel iedereen nageleefd.

Het enige puntje waar twijfel over is, zijn openingsaccolades. Die horen op dezelfde regel te staan, maar worden er ook vaak onder geplaatst. Kwestie van smaak.

[Gonadan]

JKVA schreef op donderdag 23 maart 2006 @ 11:47:
Leer jezelf dan ook meteen aan dat in Java de Hungarian notatie niet gebruikt wordt. Zie link:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html, hoofdstuk 9: naming conventions.

Dat is de standaard en die wordt door vrijwel iedereen nageleefd.

Het enige puntje waar twijfel over is, zijn openingsaccolades. Die horen op dezelfde regel te staan, maar worden er ook vaak onder geplaatst. Kwestie van smaak.

Ik vind dat ze bij JAVA er achter horen, ik vind het ook makkelijker leesbaar, je ziet wat er bij het block hoort. Maar da's maar een mening

[bvp]

Gonadan schreef op donderdag 23 maart 2006 @ 11:49:
[...]

Ik vind dat ze bij JAVA er achter horen, ik vind het ook makkelijker leesbaar, je ziet wat er bij het block hoort. Maar da's maar een mening

offtopic:
HELEMAAL mee eens!

[JKVA]

Ik vind ook dat erachter netter is, maar je ziet toch nog vaak dat ze eronder staan omdat dan de scope duidelijker is. Maar goed, het maar weer een mening. Zolang Eclipse mijn opmaak verzorgt, vind ik het allemaal best. Typen, typen, typen, ctrl + shift + f en klaar is Kees.

[Robtimus]

bvp schreef op donderdag 23 maart 2006 @ 11:27:
Tja kan zo.
Kunt ook gewoon in de class Product een methode getName() definieren en die aan de JList toevoegen. String is immers ook een Object

Dan houd je je toString() method voor het uitprinten van het gehele object Product -> dus bijv id EN name.

Nadeel daarvan is dat je, om bv een referentie naar het geselecteerde product te krijgen, weer moeilijk moet gaan doen met maps oid. Het fijne van JList, JTrees, JTables etc is dat omdat er juist Objects in gaan je alles op 1 plek opgeslagen houdt.
Dus niet zoals in bv VB eerst de naam uit je list halen en dan ergens anders het product voor die naam opzoeken, nee je haalt meteen je product uit de list.

Dat je daardoor minder informatie in je toString kan stoppen is jammer maar helaas. Als ik die info nodig heb voor debuggen dan schrijf ik wel een eigen method die dat doet. Ik kan niet de models voor JList etc aanpassen*, dus dan maar de debugging info.


* Natuurlijk kun je je eigen model gaan schrijven, maar om dat alleen te doen om je objecten anders af te beelden vind ik teveel moeite.

[Janoz]

JKVA schreef op donderdag 23 maart 2006 @ 11:47:
Leer jezelf dan ook meteen aan dat in Java de Hungarian notatie niet gebruikt wordt. Zie link:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html, hoofdstuk 9: naming conventions.

Dat is de standaard en die wordt door vrijwel iedereen nageleefd.

Het enige puntje waar twijfel over is, zijn openingsaccolades. Die horen op dezelfde regel te staan, maar worden er ook vaak onder geplaatst. Kwestie van smaak.

Het verschil in plaatsing van een accolade is marginaal in vergelijking met de case eisen. Als jij een stuk code schrijft dat anderen moeten gebruiken (dus aanroepen, en niet aanpassen) dan merk je niks meer van de plek van een accolade, maar destemeer van de gebruikte case. Het vastleggen van een globale taal specifieke eis voor de plaatsing van een accolade vind ik zelf dan ook een beetje onzin (tenzij uiteraard binnen een project, projectgroep, afdeling of bedrijf)

[JKVA]

Janoz schreef op donderdag 23 maart 2006 @ 13:00:
[...]


Het verschil in plaatsing van een accolade is marginaal in vergelijking met de case eisen. Als jij een stuk code schrijft dat anderen moeten gebruiken (dus aanroepen, en niet aanpassen) dan merk je niks meer van de plek van een accolade, maar destemeer van de gebruikte case. Het vastleggen van een globale taal specifieke eis voor de plaatsing van een accolade vind ik zelf dan ook een beetje onzin (tenzij uiteraard binnen een project, projectgroep, afdeling of bedrijf)

?

Ik begrijp niet helemaal wat je bedoelt. Ik ben het er wel mee eens dat zulke code te lezen is, maar aan de andere kant zijn conventies er om nageleefd te worden. Dit wordt in de Javawereld vrij goed gedaan en daar ben ik wel blij om, als ik het vergelijk met bijvoorbeeld PHP. (dit is geen flame)

Het is een kwestie van smaak wat je het meest netjes vindt ogen, maar je moet niet per persoon een eigen stijl gaan naleven.

Maar goed, het dwaalt af...

[Janoz]

Wat ik meer bedoel is dat een conventie over case een stuk meer impact heeft dan een conventie over op welke plek je de accolade zet (nieuwe regel, zelfde regel). Het eerste zorgt ervoor dat een api of andere library fundamenteel anders wordt terwijl het laatste verschil alleen van invloed is wanneer je daadwerkelijk met de code aan het werk moet. Natuurlijk moet er over het laatste ook afspraken gemaakt worden, maar de scope van die afspraken hoeven wat mij betreft niet verder te gaan dan een project, afdeling of onderneming. Het lijkt mij bijvoorbeeld niet wenselijk dat sun verplicht dat iedereen in zijn javacode de accolade op een nieuwe regel zet en dat hij zijn tabafstand op 2 spaties zet.

[PhoneTech]

wat een off topioc geneuzel. Ik zet altijd de accolades op een nieuwe regel. Veel duidelijker vind ik zelf.

Maar even on topic. Je kan ook middels een ListCellRenderer de juiste contents rendereren als je niet de toString method wilt gebruiken:

Java:

new JList().setCellRenderer(new ListCellRenderer()
        {
        
            public Component getListCellRendererComponent(JList list, Object value, int index,
                    boolean isSelected, boolean cellHasFocus)
            {
                Product p = (Product)value;
                return p.getName();
            }
        
        });

[Robtimus]

PhoneTech schreef op donderdag 23 maart 2006 @ 14:53:
Maar even on topic. Je kan ook middels een ListCellRenderer de juiste contents rendereren als je niet de toString method wilt gebruiken:

Java:

new JList().setCellRenderer(new ListCellRenderer()
        {
        
            public Component getListCellRendererComponent(JList list, Object value, int index,
                    boolean isSelected, boolean cellHasFocus)
            {
                Product p = (Product)value;
                return p.getName();
            }
        
        });

Dat kan ook, maar ik zou het toch wel zeker anders implementeren:
subclass van DefaultCellRenderer (of hoe dat ding ook heet), het Component via de super opvragen, en (aangezien dat een JLabel is) via setText de text veranderen.

[PhoneTech]

IceManX schreef op donderdag 23 maart 2006 @ 18:01:
[...]
Dat kan ook, maar ik zou het toch wel zeker anders implementeren:
subclass van DefaultCellRenderer (of hoe dat ding ook heet), het Component via de super opvragen, en (aangezien dat een JLabel is) via setText de text veranderen.

Hier heb je ook helemaal gelijk in. het voorbeeldje was ook niets meer dan een proof of concept.
Veel beter is om van de DefaultListCellRenderer te extenden. Dan zet hij ook meteen de kleuren goed als de cell geselecteerd is.