🚀 go-pugleaf

* shio wrote, On 2008-10-31 09:05:

>> IMHO tez dialog nie powinien sam na sobie wolac setVisible(true), 
>> powinien to zrobic ktos kto go wywoluje (np. button). Dzieki temu 
>> dialog  nie 'zawisnie' Ci w konstruktorze na tej metodzie, ale wlasnie 
>> poczeka na powrot z dialogu tam gdzie go wywolales, czyli masz to co 
>> chciales osiagnac :)
> 
> rzeczywiscie takie zalozenie zalatwia sprawe, dotychczas usilnie 
> stosowalem podejscie umieszczania setVisible(true) na koncu metody
> inicjujacej formatke, po stworzeniu wszystkich komponentow. Tak bylo 
> prosciej.. np z menu aplikacji czy z buttona utworzyc nowy obiekt 
> konstruktorem i mozna bylo zapomniec o nim.

Czy prosciej to tez nie wiadomo bo co jesliby formatka miala cos 
zwracac? Ja zwykle robilem tak (pseudokod z palca):

btnAddUserActionPerformed()
{
   UserDialog ud = new UserDialog(null); //null by odroznic od edycji
   ud.setVisible(true); //czekamy az formatka zostanie zamknieta, 
obojetnie czy przyciskiem 'dodaj' czy 'anuluj'
   ResultEnum result = ud.getResult();

   if(result == ResultEnum.OK)
   {
     User u = ud.getUser();
     UserDAO.save(u);
   }
}

oczywiscie powyzszy kod wymaga troche dodatkowej logiki w dialogu (ktora 
mozna zalatwic w jednym, abstrakcyjnym dialogu) takiej jak zapis kodu 
przycisku po nacisnieciu oraz zapis wpisanych danych przy nacisnieciu 
'OK', ale to tez w dobie typow generycznych mozna ladnie wyniesc wyzej 
do jakiejs abstrakcji i np. getUser() zastapic getObject(), ktory bedzie 
  zwracal <T>, ktorym bedzie parametryzowany dialog.

ew. mozna zrobic w dialog metode showDialog(), ktora wola setVisible i 
zwraca np. kod/enum w jakis sposob dialog zostal zamkniety, wtedy robisz 
tak:

   UserDialog ud = new UserDialog(null); //null by odroznic od edycji
   DialogResult result = ud.showDialog();

   if(result == ResultEnum.OK)
   {
   }
   else if(result == ResultEnum.Cancel)
   {
   }
   //itd.


-- 
Krzysztof Wolny

kkk.wolny@gmail.com (replace 'kkk' with one 'k')