[java] GUI observing Vector

[Verwijderd]

Stel ik heb een class BusinessData als

code:

public class BusinessData 
{
  public Vector listString; // bevat lijstje strings
  public Vector listInt; // euh.. lijstje ints dus

  // ...
}

Verder heb ik een class voor GUI als

code:

public class SomeGUI extends JFrame
{
  private JPanel topPanel;
  private JList list_voor_listString;
  private JList list_voor_listInt;
    
  public SomeGUI()
  {
    setTitle("DSU GUI");
    setSize(400, 200);
    setBackground(Color.gray);
    //..etc.
  }  
}

Wat ik nu graag zou willen is dat de correcte GUI component automatisch geupdate worden als de betreffende Vectors van inhoud veranderen. Ik heb me suf gelezen over dit onderwerp, maar kom niet tot een (fraaie) oplossing..

[whoami]

Observer design pattern

In Java heb je trouwens de IObserver en IObservable interface dacht ik, misschien moet je daar eens naar kijken.

[Verwijderd]

Maar JList is Swing en die zou volgens de docs al een vorm van Model-View-Controller, bevatten alleen bevat ik nog niet zo goed hoe je die Vectors het 'model' van de JList (= 'View-Controller') laten zijn..

[whoami]

Lees even dat stukje over het observer pattern.

Je Vector is je 'subject' of 'model', je GUI is je observer. Je subject (Vector) houdt een verwijzing bij naar z'n observers (gui's), en als er iets wijzigt in je subject, dan roept je subject de Update() method aan van iedere observer (GUI) dat bij dat subject 'geregistreerd' is.

[wasigh]

http://java.sun.com/j2se/...pi/javax/swing/JList.html

Swing werkt met modellen, als je die modellen aanpast past het swing component zicht automatisch aan. Maar dat staat allemaal beschreven in de Api-doc

en daar staat onder ander dit:

code:

 Vector superClasses = new Vector();
 Class rootClass = javax.swing.JList.class;
 for(Class cls = rootClass; cls != null; cls = cls.getSuperclass()) 
{
     superClasses.addElement(cls);
 }
 JList classList = new JList(superClasses);

Je kunt dus de Vector meegeven in de Constructor van de JList.

[ Voor 7% gewijzigd door wasigh op 07-01-2004 20:21 ]

[Verwijderd]

wasigh schreef op 07 januari 2004 @ 20:21:
Je kunt dus de Vector meegeven in de Constructor van de JList.

Was het maar zo makkelijk; dat kan wel maar dan heb je dus een statische lijst en niet eentje die de datastructuur 'observed'..

[wasigh]

code:

public void setListData(Vector listData)
protected void fireSelectionValueChanged(int firstIndex,
                                         int lastIndex,
                                         boolean isAdjusting)

Die geprobeerd?

of anders:
http://java.sun.com/docs/...wing/components/list.html
http://java.sun.com/produ...topics/jlist_1/jlist.html
??

[ Voor 83% gewijzigd door wasigh op 07-01-2004 20:50 ]

[nxt]

wat je zou kunnen doen is een class maken die

javax.swing.AbstractListModel extends

en als je een instantie daarvan meegeeft aan een JList via de constructor
heb je binnen die instantie de beschikking over de volgende methods
fireContentsChanged
fireIntervalAdded
en fireIntervalRemoved

als je die op de aanroept wanneer er data bijkomt/verwijderd word/veranderd, dan dan zal de JList instance automatisch zichzelf updaten.


en dan kun je bijvoorbeeld ook de java.util.List interface implementeren en al die methods doorsluizen naar een (private) Vector zodat je die class op dezelfde manier kunt gebruiken als een vector.


edit @wasigh:
setListData gebruiken heeft volgens mij niet veel zin omdat de parameters als final gedeclareerd zijn en dus niet kunnen wijzigen,

setListModel( ...) zou wel kunnen

en fireSelectionValueChanged gaat afaik alleen over welke waardes uit de JList geselecteerd zijn

maar in je 2e link staat dat listmodel wel erg mooi uitgelegd

[ Voor 23% gewijzigd door nxt op 07-01-2004 21:14 ]

[Verwijderd]

nxt allereerst bedankt voor je reactie. Jou voorstel bestaat al in de vorm van DefaultListModel. Een mogelijke oplossing is dus om alle Vectoren te vervangen door DefaultListModels alleen vind ik dit niet zo 'mooi', maarja 't werkt wel goed

[nxt]

Verwijderd schreef op 07 januari 2004 @ 21:36:
nxt allereerst bedankt voor je reactie. Jou voorstel bestaat al in de vorm van DefaultListModel. Een mogelijke oplossing is dus om alle Vectoren te vervangen door DefaultListModels alleen vind ik dit niet zo 'mooi', maarja 't werkt wel goed

idd, je hebt gelijk,
stom dat ik die over het hoofd gezien heb.
als je de List interface niet nodig hebt lijkt 't me een prima class (en scheelt natuurlijk weer wat typewerk )

maar in elk geval is voor zover ik weet een ListModel de enige mogelijkheid voor wat je wilt.

[wasigh]

nxt schreef op 07 januari 2004 @ 21:07:


edit @wasigh:
setListData gebruiken heeft volgens mij niet veel zin omdat de parameters als final gedeclareerd zijn en dus niet kunnen wijzigen,

setListModel( ...) zou wel kunnen

en fireSelectionValueChanged gaat afaik alleen over welke waardes uit de JList geselecteerd zijn

maar in je 2e link staat dat listmodel wel erg mooi uitgelegd

Ik weet er het fijne ook niet van ik heb er nooit meegewerkt, maar ik weet wel dat het in de api-doc goed beschreven staat

Mijn reactie was: hier kun je het vast wel vinden, ipv een complete oplossing

[Bluestorm]

Wat ik me er van kan herinneren is... dat je GUI de Observer is. en je BusinessData de Observable. Een Observable 'kent' als zijn observers en kan met een methode notifyObservers() oid aangeven dat hij veranderd is. De Observer kan daar dan wat mee doen. ( notifyObservers roept volgens mij voor ieder Observer object een methode aan welke in de observer interface gedefinieerd staat... waarbij onderandere het gewijzigde object als argument wordt gebruikt)

Dan moet de Observable zelf natuurlijk wel weten wanneer ie veranderd. Je zou bijvoorbeeld je Vectoren private kunnen maken en deze met methodes in BusinessData updaten. En dan ook meteen notifyObservers aanroepen.

Voordeel van gewoon Observer/Observable gebruiken is dat 't ook voor andere dingen te hergebruiken is dan alleen voor je Swing interface.

[ Voor 11% gewijzigd door Bluestorm op 07-01-2004 21:54 ]

[Verwijderd]

Bluestorm schreef op 07 januari 2004 @ 21:45:
Voordeel van gewoon Observer/Observable gebruiken is dat 't ook voor andere dingen te hergebruiken is dan alleen voor je Swing interface.

True, nadeel is echter dat je een subclass moet maken van Observable en meestal zijn classes al een subclass en dan moet je weer een delegating wrapper maken en das allemaal gedoe. Verder is het vrij lomp om dit te implementeren als de Swing classes zelf al een mvc basis hebben..

Verder had ik gehoopt dat iemand met een fantastisch alternatief kwam, want wat als ik ipv een HashMap, String of whatever will gaan observen, dan moet ik dus alsnog zelf een implementatie schrijven die AbstractListModel extends en als ik besluit dat ik de gegevens ook in een JTree wil knallen dan moet ik allemaal nieuwe classen maken die weer van AbstractListModel subclassen. Al met al een hoop error-gevoelig werk..

[ Voor 30% gewijzigd door Verwijderd op 08-01-2004 09:14 ]

[Verwijderd]

-Kick-

Dit is toch iets waar ieder Java mee te maken heeft (gehad)?

[Verwijderd]

voorbeeld
ge extends te klasse vector

myVector

override elke methode (add, delete)

public void add(Object o){
super.add(o);
setChanged();
}

setChanged wijzigt dan de status!