Java MVC en Listener probleem

[Verwijderd]

Een klasse Artikel:

code:

public class Artikel {
  private String _naam = "";
  private float _prijs = 0;

  public Artikel() {
  }

  public void setNaam(String nieuweNaam) {
    this._naam = nieuweNaam;
  }

  public void setPrijs(float nieuwePrijs) {
    this._prijs = nieuwePrijs;
  }

  public String getNaam() {
    return this._naam;
  }

  public float getPrijs() {
    return this._prijs;
  }
}

Een klasse ArtikelenLijst:

code:

public class ArtikelenLijst {
  private Vector _artikelen = new Vector();

  public ArtikelenLijst() {
  }

  public void addArtikel(Artikel artikel) {
     _artikelen.addElement(artikel);
  }

  public void removeArtikel(int positie) {
    _artikelen.removeElementAt(positie);
  }

  public Artikel getArtikel(int positie) {
    return (Artikel) _artikelen.elementAt(positie);
  }
}

Nu heb ik een JTable die de Artikelen moet weergeven. De bijbehorende TableModel haalt de gegevens uit de ArtikelenLijst. Nu wil ik echter dat als bijv. de prijs van een artikel verandert dat direkt zichtbaar is in de JTable. Hoe doe ik dit op een nette manier? Moet ik de ArtikelenLijst laten luisteren naar elk Artikel en vervolgens de ArtikelenLijst een event laten genereren die wordt opgevangen door het TableModel, die vervolgens een fireTableDataChanged() spuugt?

A.u.b. geen gezeur over vriendelijke functies want de code is een beknopt overzicht.

Zo nu eerst ff wat eten.

[Alarmnummer]

Dat is inderdaad een interessant probleem, waar ik zelf ook mee te maken heb gehad. Je zal sowieso even events voor changes bij de Artikel moeten genereren. Dit zou je kunnen doen mbv PropertyChangeSupport.

Je zou 2 dingen kunnen doen:
1) je laat de TableModel naar iedere eigenschap van artikelen luisteren. Het probleem is dat je dus voor iedere cel dus ook een listener hebt. Het voordeel is dat je weet welke cel het is en dat niet achteraf hoeft uit te zoeken. Daarnaast is die gewoon een elegante manier die zich verder niets aantrekt van performance of geheugen verbruik.

2)je laat de TableModel naar ieder artikel luisteren of er in het geheel een change is opgetreden (dus hij luisterd naar alle eigenschappen tegelijk). Het voordeel van deze aanpak is dat je veel minder listeners nodig bent en dus ook minder opslag plaats. Het nadeel is dat je achteraf weer terug moet redeneren wat veranderd is. (Dat zou je kunnen doen mbv de Property naam van het PropertyChangeEvent). En verder ondersteunt PropertyChangeSupport ook het luisteren naar alle eigenschappen.

Als dit voor een schoolopdracht is, zou ik lekker de purist gaan uithangen en manier 1 gebruiken. Is het voor echt gebruik, dan zou ik optie 2 gaan overwegen.

Zie trouwens verder: [rml][ Java] ListSupport voor de liefhebbers. *[/rml]

Hiermee kan je heel eenvoudig een TableModel aansluiten op een List..

PS dit is al vet oude code en ik ben al met iets leukers bezig En natuurlijk alles is geparametriseerd

PS2: zorg er voor de je de listeners ook weer verwijderd bij de model, want anders heb je een memoryleak.

[Verwijderd]

Alarmnummer schreef op 20 november 2002 @ 12:31:
... Je zal sowieso even events voor changes bij de Artikel moeten genereren. Dit zou je kunnen doen mbv PropertyChangeSupport.

Die events heb ik er al tussengestopt (mbv PropertyChangeSupport) maar heb ze voor de omschrijving eerst maar even weggelaten.

Als dit voor een schoolopdracht is, zou ik lekker de purist gaan uithangen en manier 1 gebruiken. Is het voor echt gebruik, dan zou ik optie 2 gaan overwegen.

't Is voor echt gebruik. 'k Heb net mijn eerste opdracht binnen ......'t Is voor een kennis. Optie 2 dan maar......

Zie trouwens verder: [rml][ Java] ListSupport voor de liefhebbers. *[/rml]

Hiermee kan je heel eenvoudig een TableModel aansluiten op een List..

'k Zal er eens naar kijken.

PS dit is al vet oude code en ik ben al met iets leukers bezig En natuurlijk alles is geparametriseerd

Bedoel je het topic: MVC kan veel generieker?

PS2: zorg er voor de je de listeners ook weer verwijderd bij de model, want anders heb je een memoryleak.

Wanneer moeten die worden verwijderd? Toch alleen wanneer je je Table verwijderd en je TableModel?

[Alarmnummer]

Verwijderd schreef op 20 November 2002 @ 13:39:
Die events heb ik er al tussengestopt (mbv PropertyChangeSupport) maar heb ze voor de omschrijving eerst maar even weggelaten.

Dat was idd wel zo handig. Had al het vermoeden dat de code alleen ter verduidelijking was.

Bedoel je het topic: MVC kan veel generieker?

yep

Wanneer moeten die worden verwijderd? Toch alleen wanneer je je Table verwijderd en je TableModel?

Zo gauw je de table verwijderd, moet je even tegen de tablemodel zeggen dat hij al zijn listeners even bij die PropertyChangeSupport instanties moet weghalen. Wat je eventueel ook zou kunnen doen is WeakReferences gebruiken. Ik ben daar zelf ook wat mee aan het experimenteren geweest omdat ik me ook heb gestoord aan memory leaks of aan het opruimen van listeners.