[JAVA] getParent() onduidelijkheid

[Verwijderd]

Hallo,

Ik zit met een probleem, waar de gemiddelde JAVA-programmeur al snel tegen aanloopt vermoed ik.

Ik heb een container met daarop een JTable en een zootje JTextfields e.d.
Nou heb ik een klasse geschreven die de tabel dynamisch opbouwt aan de hand van de sql-query. Ik heb een event op de tabel die zodra deze getriggerd wordt de JTextfields zou moeten gaan vullen.

Ik vindt het alleen zwaar overbodig om steeds weer die container mee te geven in alle klassen. Nu heb ik begrepen dat daar een fenomenale getParent voor bestaat. Als ik deze echter doe op de JTable, krijg ik de prachtigste containers terug behalve de goede. Als ik van de parent weer de parent opvraag enz. dan krijg ik op den duur wel iets wat er op lijkt, maar als ik van deze de namen van de componenten opvraag heten deze allemaal null.

Iemand enig idee?

[hobbit_be]

wat moet er op de textfields verschijnen? ik neem aan dat het een 'record' editor is?
persoonlijk moet je zo min mogelijk werken met Swing maar gewoon een classe die de functionaliteit implementeerd:

Java:

class theEditor extends JPanel
  implements ActioNListerener (or welke interfaces je spul afschieten)
{
   JTable mTable;
   ArrayList mEditors;
}

zo is je code veel meer portable -deze class is dus de 'link' of de manager van in weze verschilldende dingen. Als je alles relatief gaat coden zit je teveel vast aan het onderliggend systeem... abstractify dear watson, abstractify. (zo'n classe kun je dan ineens weer multiple copies en zo van nement).

[Verwijderd]

hobbit_be schreef op 18 May 2003 @ 17:05:
wat moet er op de textfields verschijnen? ik neem aan dat het een 'record' editor is?
persoonlijk moet je zo min mogelijk werken met Swing maar gewoon een classe die de functionaliteit implementeerd:

Java:

class theEditor extends JPanel
  implements ActioNListerener (or welke interfaces je spul afschieten)
{
   JTable mTable;
   ArrayList mEditors;
}

zo is je code veel meer portable -deze class is dus de 'link' of de manager van in weze verschilldende dingen. Als je alles relatief gaat coden zit je teveel vast aan het onderliggend systeem... abstractify dear watson, abstractify. (zo'n classe kun je dan ineens weer multiple copies en zo van nement).

Het is inderdaad gewoon een recordeditor en ik heb al een aantal klassen die redelijk universeel inzetbaar zijn. (De tabel leest zelf de velden van de query uit e.d.) De namen van de tekstvelden komen overeen met de veldnamen in de database, dus wat dat betreft zou dit dus ook universeel inzetbaar moeten blijven.

Uiteraard zal het zo zijn dat het een en ander nog beter kan, maar helaas volg ik een zoek-alles-toch-lekker-fijn-zelf-uit-opleiding waar ze je laten zien hoe je met settext een veld vult om vervolgens een volledig werkende applicatie te moeten kunnen schrijven. Zo is mij nog nooit geleerd wat een abstracte klasse is, ik ga er van uit dat het een klasse is die ongeacht het project weer inzetbaar is. Als dit zo is dan zitten we in ieder geval op 1 lijn ,want daar ben ik dus druk mee bezig.

Ik heb alleen weinig aan je huidige uitleg wat betreft hte getParent() probleem. Ik krijg dus wel containers terug, maar het zijn niet de juiste of ik spreek ze verkeerd aan.

[hobbit_be]

tja die classe (helemaal niet abstract hoor, abstraction is ruimer: zoveel mogelijk logic lagen in je code steken, voor reusability). Maar de classe die ik liet zien is dat je niet met getParent().getParent().getParent() enzo dingen moet coden - een heel lijst ga ik hier niet opnoemen. Je moet gewoon je Table (en Model) en de lijst van je Textfields in een 'Containment' calss steken. Zodoende hoef je helemaal geen relatief spul gebruiken (mocht je ooit het design of layout verandered). Overigens voor je getParent is er niet genoeg info: zit je Table in een scroll table zit die dan weer in een JPanel, en waar en in welke container zitten je Textfields enzovoorts.

Het mag dus duidelijk zijn dat je NOOIT je UI je code mag doen bepalen... (tot zoverre dat dat mogelijk is)

[Verwijderd]

hobbit_be schreef op 18 mei 2003 @ 20:27:
tja die classe (helemaal niet abstract hoor, abstraction is ruimer: zoveel mogelijk logic lagen in je code steken, voor reusability). Maar de classe die ik liet zien is dat je niet met getParent().getParent().getParent() enzo dingen moet coden - een heel lijst ga ik hier niet opnoemen. Je moet gewoon je Table (en Model) en de lijst van je Textfields in een 'Containment' calss steken. Zodoende hoef je helemaal geen relatief spul gebruiken (mocht je ooit het design of layout verandered). Overigens voor je getParent is er niet genoeg info: zit je Table in een scroll table zit die dan weer in een JPanel, en waar en in welke container zitten je Textfields enzovoorts.

Het mag dus duidelijk zijn dat je NOOIT je UI je code mag doen bepalen... (tot zoverre dat dat mogelijk is)

Euh... Voor zo ver ik het begrijp stel je voor dat ik een aparte klasse maak, waar ik de objecten die ik in meerdere klasses gebruik in set. Instantie van deze klasse steeds meegeven, zodat je je containers e.d. aan kunt spreken op het moment dat je dat wilt. Is dit in feite niet een workaround? Het neigt in mijn ogen naar het simuleren van een globale variabele. Ik kan me voorstellen dat het onoverzichtelijk wordt op het moment dat je tig objecten op deze manier wilt gaan gebruiken.

[Woy]

Verwijderd schreef op 19 mei 2003 @ 10:06:
[...]


Euh... Voor zo ver ik het begrijp stel je voor dat ik een aparte klasse maak, waar ik de objecten die ik in meerdere klasses gebruik in set. Instantie van deze klasse steeds meegeven, zodat je je containers e.d. aan kunt spreken op het moment dat je dat wilt. Is dit in feite niet een workaround? Het neigt in mijn ogen naar het simuleren van een globale variabele. Ik kan me voorstellen dat het onoverzichtelijk wordt op het moment dat je tig objecten op deze manier wilt gaan gebruiken.

Nee het is eerder een netere oplossing dan met getParent(). Want stel je hebt eerst de volgende code die werkt.

getParent().getParent().getParent().setText( "blaat" );

en dan wil je bijvoorbeeld een extra container tussenvoegen. Dan moet je overal in je code een extra getParent() gaan toevoegen. Als je gewoon een referentie naar een object hebt kun je daar direct bij en haalt het niet uit waar hij staat. Je kunt dan zelfs later besluiten om je TextField in een ander scherm te zetten ofzo en dan hoef je niks aan je code te veranderen.

[Verwijderd]

rwb schreef op 19 mei 2003 @ 10:35:
[...]

Nee het is eerder een netere oplossing dan met getParent(). Want stel je hebt eerst de volgende code die werkt.

getParent().getParent().getParent().setText( "blaat" );

en dan wil je bijvoorbeeld een extra container tussenvoegen. Dan moet je overal in je code een extra getParent() gaan toevoegen. Als je gewoon een referentie naar een object hebt kun je daar direct bij en haalt het niet uit waar hij staat. Je kunt dan zelfs later besluiten om je TextField in een ander scherm te zetten ofzo en dan hoef je niks aan je code te veranderen.

Hmmmm, ok.
Ik ben het eens met deze gedachtengang, want inderdaad als je je gui wijzigt loop je een grote kans dat je meerdere klasses aan moet passen. Het is dan inderdaad een betere manier om een aparte klasse te gebruiken voor het storen van een aantal belangrijke objecten. Feit blijft wel dat ik deze manier (ondanks dat deze universeler inzetbaar is) over vindt komen als een workaround, aangezien je een globale variabele simuleert. Is er geen betere manier? tsssk... word wel lekker theoretisch zo

[Woy]

Verwijderd schreef op 19 mei 2003 @ 12:15:
[...]


Hmmmm, ok.
Ik ben het eens met deze gedachtengang, want inderdaad als je je gui wijzigt loop je een grote kans dat je meerdere klasses aan moet passen. Het is dan inderdaad een betere manier om een aparte klasse te gebruiken voor het storen van een aantal belangrijke objecten. Feit blijft wel dat ik deze manier (ondanks dat deze universeler inzetbaar is) over vindt komen als een workaround, aangezien je een globale variabele simuleert. Is er geen betere manier? tsssk... word wel lekker theoretisch zo

Ik snap niet echt waarom je het als een globale variabele ziet? Als je een static variabele zou gebruiken zou ik het snappen maar de eigenschap van een globale variabele is dat alles er gebruik van kan maken. Bij deze manier is dat echter niet zo want alleen de classes die je de referentie meegeeft maken er gebruik van. Je zou ook meerdere instanties van de objecten kunnen maken en dan kan je zelf kiezen welk object met welk textfield werkt bijvoorbeeld.

[Verwijderd]

rwb schreef op 19 May 2003 @ 12:56:
[...]


Ik snap niet echt waarom je het als een globale variabele ziet? Als je een static variabele zou gebruiken zou ik het snappen maar de eigenschap van een globale variabele is dat alles er gebruik van kan maken. Bij deze manier is dat echter niet zo want alleen de classes die je de referentie meegeeft maken er gebruik van. Je zou ook meerdere instanties van de objecten kunnen maken en dan kan je zelf kiezen welk object met welk textfield werkt bijvoorbeeld.

Het is ook geen globale variabele, want je geeft netjes een instantie mee, waar je het weer aan vraagt. Het gaat mij er meer om dat je een speciale klasse maakt om variabelen/objecten beschikbaar te maken in alle klassen. In die zin is het te vergelijken (tot op zekere hoogte) met een globale variable. Qua structuur is dit uiteraard helderder, want je kunt ook zien waar die het object vandaan haalt.
Ik vraag me af of dit qua OO ook correct is, want je hebt een feite een klasse met daarin een verzamelbak van allerlei objecten die geen onderling verband hebben.
Je klasse gaat overal en nergens over om het zo maar te zeggen.

Ik vraag me dus af of dit gewoon ook mag qua OO-theorie en doodnormaal is of dat het een oplossing is om objecten maar beschikbaar te hebben wanneer en waar je dat wil.
Zoals ik al zei, erg theoretisch (want ik ga het wel zo toepassen), maar ik ben gewoon benieuwd.

[Woy]

Verwijderd schreef op 19 May 2003 @ 13:22:
[...]


Het is ook geen globale variabele, want je geeft netjes een instantie mee, waar je het weer aan vraagt. Het gaat mij er meer om dat je een speciale klasse maakt om variabelen/objecten beschikbaar te maken in alle klassen. In die zin is het te vergelijken (tot op zekere hoogte) met een globale variable. Qua structuur is dit uiteraard helderder, want je kunt ook zien waar die het object vandaan haalt.
Ik vraag me af of dit qua OO ook correct is, want je hebt een feite een klasse met daarin een verzamelbak van allerlei objecten die geen onderling verband hebben.
Je klasse gaat overal en nergens over om het zo maar te zeggen.

Ik vraag me dus af of dit gewoon ook mag qua OO-theorie en doodnormaal is of dat het een oplossing is om objecten maar beschikbaar te hebben wanneer en waar je dat wil.
Zoals ik al zei, erg theoretisch (want ik ga het wel zo toepassen), maar ik ben gewoon benieuwd.

Je hoeft natuurlijk ook niet een apart object te maken. Je kan ook gewoon de velden die je nodig hebt doorgeven. Als dit er veel zijn en wel wat met elkaar te maken hebben kan je het met een array oid doen.

[hobbit_be]

Containment in OO is heel normaal en zelfs aan te raden (ie dus een classe die andere classen bevat dan die uit te breiden, en aangezien Java niet eens multiple ingeritance aankan is het helemaal niet echt goed mogelijk). Het gebruik van Interfaces is altijd aan te raden (met dan contained classes die helpen bij het implementern van je interfaces).

Bjorne van C++ fame zegt zelf in zijn boek dat multiple inheritance eigenlijk (in C++) best vermeden kan worden (op moeten na).

Waar je idee van global vandaan komt snap ik niet. In jouw geval is ie er mischien maar instance maar dat heeft met jouw programma te maken niets met OO.

View1 = new TableEditor("Select * FROM hello");
View2 = new TableEditor("Select * FROM dummy");

deze kun je dan in een TabbedLayout propppen ofzo.

Om te zeggen dat de textfields niet te maken hebben met je table(model) is helemaal onjuist. Het feit dat beide met dezelfde dat moeten werken moet al een belletje doen ringen dat deze tesamen horen (ie het veranderen van de ene beibnvloed de andere). Die class is dus de 'glue' of 'logic' die twee UI elements bij elkaar houd, net zoals een Toolbar ook bestaat uit 1 JPanel en een lijst van subpanels.

Een containment class gebruik je om bepaalde elementen te groeperen. Het grote main class 'classe' is daar ook een typsich voorbeeld van. Een global variable in Java is trouwens erg uitzonderlijk: meestal word er een static in een member gezet en hoewel dit global is is het ook een beetje 'context'.

Maar het belangrijkste concept is toch het UI / Data dat je altijd tot zover het mogelijk is moet proberen te vermijden. OO is 'Object Oriented' getParent() lijkt mishcien meer OO maar is het helemaal niet, is gewoon een 'Tree' Model...

Dus: alles wat logisch bij elkaar past in een classe zetten. En dat mag best ver gaan. Hoever hangt af van ervaring. In jouw geval is het echt een 'Must Do'...

[Verwijderd]

hobbit_be schreef op 19 mei 2003 @ 15:01:
Containment in OO is heel normaal en zelfs aan te raden (ie dus een classe die andere classen bevat dan die uit te breiden, en aangezien Java niet eens multiple ingeritance aankan is het helemaal niet echt goed mogelijk). Het gebruik van Interfaces is altijd aan te raden (met dan contained classes die helpen bij het implementern van je interfaces).

Bjorne van C++ fame zegt zelf in zijn boek dat multiple inheritance eigenlijk (in C++) best vermeden kan worden (op moeten na).

Waar je idee van global vandaan komt snap ik niet. In jouw geval is ie er mischien maar instance maar dat heeft met jouw programma te maken niets met OO.

View1 = new TableEditor("Select * FROM hello");
View2 = new TableEditor("Select * FROM dummy");

deze kun je dan in een TabbedLayout propppen ofzo.

Om te zeggen dat de textfields niet te maken hebben met je table(model) is helemaal onjuist. Het feit dat beide met dezelfde dat moeten werken moet al een belletje doen ringen dat deze tesamen horen (ie het veranderen van de ene beibnvloed de andere). Die class is dus de 'glue' of 'logic' die twee UI elements bij elkaar houd, net zoals een Toolbar ook bestaat uit 1 JPanel en een lijst van subpanels.

Een containment class gebruik je om bepaalde elementen te groeperen. Het grote main class 'classe' is daar ook een typsich voorbeeld van. Een global variable in Java is trouwens erg uitzonderlijk: meestal word er een static in een member gezet en hoewel dit global is is het ook een beetje 'context'.

Maar het belangrijkste concept is toch het UI / Data dat je altijd tot zover het mogelijk is moet proberen te vermijden. OO is 'Object Oriented' getParent() lijkt mishcien meer OO maar is het helemaal niet, is gewoon een 'Tree' Model...

Dus: alles wat logisch bij elkaar past in een classe zetten. En dat mag best ver gaan. Hoever hangt af van ervaring. In jouw geval is het echt een 'Must Do'...

Ik begin het steeds beter te begrijpen Ik ben er al wel achter dat je op dit forum wat concretere antwoorden krijgt dan van de gemiddele docent. Die blaten er ook maar wat om heen, omdat ze het zelf ook niet begrijpen heb ik wel eens het idee.
Ik wil wel even 1 ding rechtzetten en dat is dat ik dus de vergelijking maak met een globale variabele en zo'n containmentklasse. Je doel is namelijk hetzelfde, een object 'globaal' beschikbaar maken. Het leek (met nadruk op leek) mij erg dirty om dan maar een klasse te maken met daarin allerlei objecten eigenlijk alleen voor het doorgeven. In die zin noem ik het vergelijkbaar. Technisch gezien is het natuurlijk volledig anders.

[Woy]

Verwijderd schreef op 19 May 2003 @ 15:31:
[...]


Ik begin het steeds beter te begrijpen Ik ben er al wel achter dat je op dit forum wat concretere antwoorden krijgt dan van de gemiddele docent. Die blaten er ook maar wat om heen, omdat ze het zelf ook niet begrijpen heb ik wel eens het idee.
Ik wil wel even 1 ding rechtzetten en dat is dat ik dus de vergelijking maak met een globale variabele en zo'n containmentklasse. Je doel is namelijk hetzelfde, een object 'globaal' beschikbaar maken. Het leek (met nadruk op leek) mij erg dirty om dan maar een klasse te maken met daarin allerlei objecten eigenlijk alleen voor het doorgeven. In die zin noem ik het vergelijkbaar. Technisch gezien is het natuurlijk volledig anders.

Nee het is niet je doel om je classes 'globaal' beschikbaar te maken. Het is je doel om je classes beschikbaar te maken in de classes die ze nodig hebben.

[hobbit_be]

het 'globaal' beschikbaar maken - ik snap nu wat je bedoelt: je vind het niet mooi om

Java:

class A
{
    B mB;
    C mC;
}

omdat dat in die klasse B en C 'global' zijn in die klasse. idd deze zijn global in de 'class scope'. maar buiten de klasse weer helemaal niet: dit is encapsulation.

Een voorbeeldje ivm jouw project:

Java:

public class JEditor
   extends JPanel
   implements ?TableSelectionListener?
{
    private JTable mTable;
    private JTableModel mTableModel;
    private ArrayList mTextFields;

    public JEditor()
    {
        mTable = new JTable(); 
        add(mTable, NORTH);
        .....
        mTable.addListener(this); //deze klasse luister naar events want deze beinvloden de mTextFields
    }

    public void setQuery(String aQuery)
    {
         //doe hier je TableModel
         //gebruik het model met column info of zo 
         //voor het aanmaken van je          TextFields
    }

    private void ?onSelectionListen?()
    {
         int tRowIndex = aEvent.getRowIndex();
         for-each(textfield)
        {
            textfield[x].setText(mModel.getFieldData(tRowIndex, x));
        }
    }
}

zoals je kunt zien bind deze class alles samen wat met het Object JEditor te maken heeft (waar zou je anders de totaal onafhandleijke TextFields en models zetten).
Ook moet de persoon helemaal niet weten hoe je nu eigenlijk werkt: hij wil enkel een een JEditor met een setQuery optie. Dus dit is een perfect voorbeeld van OO. (zo kan bijvoorbeeld niet aan het Model van de table buiten de classes, aangezien dit niet nodig is). Moet je het helemaal echt proper dan maak je nog een interface van de methods die deze editor classificieren:

Java:

interface IsRDBTableEditor
{
    void setQuery(String aString);
}

...

class JEditor implements IsRDBTableEditor ....

zodoende kun je later de editor vervangen zonder ook maar iets anders in je code aan de raken. (of meerdere editors die allemaal hetzelfde doen). Interfaces zijn in zo';n geval veel beter dan Inheritance.

Wel moet je oppassen met 'global' dat wil in elke taal echt wel zeggen dat ie in de allerhoogste scope zit (dus buiten de classe).