• 18/01/2006 15:32
• 

• Git! 0

  Kit! 0

otóż mam taki problem: mam obiekt klasy dziedziczącej po JApplecie - w trakcie działania programu muszę wielokrotnie podmieniać MouseListener i MouseMotionListener tego obiektu (czasem będzie to null a czasem jeden z moich MouseListenerów - działanie każdego z moich MouseListenerów jest całkowicie odmienne - zdecydowanie nie mogą być połączone w jedną klasę).
no więc proste removeMouseListener() i addMouseListener() nie działa poprawnie (tzn działają ale dają _bardzo_ nieoczekiwane efekty, a po chwili 100% zużycia procesora i literalnie setki wyjątków).

No więc jak poprawnie podmienić MouseListener'a? lub ewentualnie ominąć ten problem? any thoughts?

• 18/01/2006 15:56
• 

• Git! 0

  Kit! 0

a co stoi na przeszkodzie żeby różne działanie listenerów umieścić w blokach instrukcji warunkowych?? bo ja nie rozumiem czemu tak nie zrobiłes...

• 18/01/2006 16:17
• 

• Git! 0

  Kit! 0

bo każdy listener ma ZDECYDOWANIE odmienne działanie - dopiero napisałem pierwszego a on ma 150 linii kodu...

- nie chcę sobie robić siana z kodu, podmiana listenera byłaby dużo sensowniejsza i klarowniejsza ("teraz ten panel działa tak; zmiana; a teraz ten sam panel działa na tej samej zawartości inaczej")

jeśli nie wykombinuję z czym jest problem to w ostateczności wyląduję na blokach ale to będzie... meh

• 18/01/2006 17:57
• 

• Git! 0

  Kit! 0

Rozwiazaniem posrednim byloby zrobienie jednego listenera, ktory stanowilby fasade i ktorego bys nie podmienial -- tylko w samym listenerze zmienialbys obiekt implementujacy "strategie" obslugi myszy. Nie wyglada to zbyt madrze (jest przekombinowane), ale jezeli rzeczywiscie nie daloby sie podmienic listenera, to da w miare przejrzysty kod.

• 18/01/2006 18:52
• 

• Git! 0

  Kit! 0

no ale co z tego że 150 linii?? może nawet mieć milion!! dajesz każde działanie w osobnej metodzie i tylko wywołujesz daną metode przekazując jej MouseEvent...

if (flaga ==1){
metoda1(e);
}
else if (flaga==2){
metoda2(e);
}

moim zdaniem to rozwiązanie jest całkiem niezłe... zwłaszcze jeśli nie potrafisz inaczej...

• 18/01/2006 18:56
• 

• Git! 0

  Kit! 0

oba rozwiazania dobre.

• 19/01/2006 00:48
• 

• Git! 0

  Kit! 0

Strategie = yes
milion lini + harmonie if-else = No (chyba ze chcesz sie zatrudnic w comarchu albo infovide :P)

• 19/01/2006 08:18
• 

• Git! 0

  Kit! 0

lini kodu akurat przy ifach będzie akurat mniej niż w rozwiązaniu które chce zrobić kolega..

• 19/01/2006 13:58
• 

• Git! 0

  Kit! 0

hehe comarch rox... cos o tym wiem hihihi

• 19/01/2006 18:22
• 

• Git! 0

  Kit! 0

Mozesz coś więcej powiedzieć o pracy w Comarch?

• 19/01/2006 18:33
• 

• Git! 0

  Kit! 0

Jednym ze sposobów na utrzymanie porządku w kodzie podczas korzystanie ze swinga jest zastosowanie wzorca Mediator.

Każdą kontrolkę, która ma reagować na jakieś zdarzenie, wyprowadzasz z klasy bazowej i implementujesz w niej interfejs listenera. Metoda listenera wywołuje odpowiednią metodę mediatora.

Przykład: Guzik, który ma coś tam zrobić.

public class Mediator {
private YouButton yourButton;

public void buttonClicked() {
/ /obsluz klikniecie guzika
}
}

public class YourButton extends JButton
implements ActionListener {
Mediator mediator;

public void actionPerformed( ActionEven event ) {
mediator.buttonClicked();
}
}

Oczywiscie, trzeba zainicjowac pola. Ja preferuję injekcję a'al Spring getterami i setterami, ale jak kto woli

Takie roziwązanie pozwala zachować rozsądny porządek w kodzie.
Można również inaczej można użyć kontenera XWork i jego implementacji Swingwork (o ile została juz wypuszczona jakas wersja RC; )) i tez dziala wyśmienicie.

Pozdrawiam.
Michał

• 19/01/2006 19:13
• 

• Git! 0

  Kit! 0

o, i z sensem, thx :)

• 19/01/2006 19:37
• 

• Git! 0

  Kit! 0

no ale jak to ma działać?? bo ja szczerze mówiąc nie do końca rozumiem jak to ma ominąć blok instrukcji warunkowych

• 19/01/2006 20:05
• 

• Git! 0

  Kit! 0

nie rozumiem jak to sie ma do tematu. wzorzec mediatora.
i tak trzeba dodawac listenera i tak, a ze w klasie Mediator jest zaimplmentowana cala logika ? co z tego ?
tutaj problemy sa raczej techniczne..
(jawka suxx so hard)

• 19/01/2006 20:27
• 

• Git! 0

  Kit! 0

gdyby nie ten nawias na końcu zgodził bym się z przedmówcą - zresztą już to wcześniej napisałem

• 19/01/2006 20:52
• 

• Git! 0

  Kit! 0

ja bym to zrobil inaczej... blah

klase w ktorej byla by kolekcja obiektow implementujacych listenera(albo jakis interfejs, wlasny interfejs). ta klasa by implmentowala listenera. routowala calosc do wszyskich obietkow w tej liscie wywolujace metode tego interfejsu.
do samego obietku by sie dodawalo normalnie obiekty, metoda addListener czy cos tam. i juz..
.

• 19/01/2006 20:58
• 

• Git! 0

  Kit! 0

to pewnie jakis design pattern ale nie pamietam jaki..
zaleta jest taka ze dodajemy raz listenera, a to co dalej sie dzieje z wiadomoscia juz zalezy od tej klasy..
do obektu zawsze mozna dodac badz usunac obiekt
np

setListener(CustomListener l) {}
removeListener(CustomListener l) {}

w kazdym momencie..

(porownujac Comparatorem czy co tam macie, referencje obietku, wsumie to nawet nie trzeba, bo operator == i tak dziala na refencjach, (nie ma zadnego przeciazania, life is suxx))

• 20/01/2006 14:28
• 

• Git! 0

  Kit! 0

no właśnie ja się na początku pytałem jak zrobić żeby podmienić MouseListener bo z moim własnym (dość rozbudowanym) nie działało poprawnie...

a co do ominięcia intrukcji warunkwych: ja chcę je tylko ominąć w sensie syntaktycznym... lubię widzieć co robi mój kod(t) :).

• 20/01/2006 14:31
• 

• Git! 0

  Kit! 0

chyba się trochę topic potomny zrobił; ) gdyby ktoś mi odpowiedział: metoda ta i ta powinna działać na 100% i jeśli nie działa to coś masz źle to bym siadł i po raz n-ty nad tym siadł i debugował; ).

• 20/01/2006 15:37
• 

• Git! 0

  Kit! 0

a co do ominięcia intrukcji warunkwych: ja chcę je tylko ominąć w sensie syntaktycznym... lubię widzieć co robi mój kod(t) :).


if (dupa)
metoda1();
else
metoda2();

czego tu nie rozymiesz??? i nie wiesz?? :/