Dotaz: Java - jak zachytit slozite podminky v GUI?

[jehovista]

Zdravim.

Potrebuju v jednom pomerne rozsahlem uzivatelskem rozhrani zachytit a spravovat velke mnozstvi podminek. Napr. zaskrtnuti jednoho checkboxu ma za nasledek, ze se musi vyplnit nejake textove pole, nebo ze vyplneni textoveho pole ma za nasledek nutnost vyplneni jineho textoveho pole a vybrani polozky z nejakeho dropdown menu. Zaroven potrebuju ohlidat, aby to fungovalo i naopak - nekde checkbox deselektuju a tim mi zmizi "constraint" jinde. Samozrejme neni problem ty podminky nabastlit do kazdeho controlleru, ale chtel bych to cele vyresit nejak elegantneji, aby se to cele dalo dobre menit/debuggovat/... a nechci znovu objevovat kolo. Aplikace uz je hotova(v ostrem provozu mnoho let) a tohle je jen nova funkce, ktera se ma dotykat radove deseti pohledu/controlleru. Chtel bych mit taky moznost nekde jednoduse v jednom miste ty podminky kontrolovat a psat na jejich zaklade ruzne udalosti(napr. se vyvola nejaky pohled s hlaskou, ze ted je nutne neco vyplnit). Existuje na to nejaka knihovna, nebo muzete alespon doporucit nejaky vhodny design pattern?

Diky

---

---

Odpovědi

[fsgsfg]

Nikdo neodpovida, tak zkusim, i kdyz v Jave neprogramuju.

Normalni toolkity (Gtk, Qt, wx) maji eventy, ktere se vyvolaji po aktualizaci nejakeho controlu (tlacitko, atd). Napriklad Qt ma QEvent::UpdateRequest, wxWidget ma wxUpdateUIEvent, Gtk ma (asi) GDK_DAMAGE). Najdi si odpovidajici event pro Javu a v nem si otestuj prislusne podminky a zarid se podle nich. Trosku zaludne je, ze kdyz pak na jejich zaklade neco zmenis, tak se zase bude vyvolavat prislusny event. Nicmene tyhle eventy casto poskytuji funkce, ktere dalsi volani eventu nevyzaduji.

[ZAH]

Java ma velmi slušně definovaný model událostí a jejich posluchačů. Viz. EventListener a rozšiřující rozhraní. Ať uz je to PropertyChangeListener, VetoableChangeListener ActionListener atd.

Spousta tříd tyto rozhraní implementují takže není většinou nezbytně nutné něco programovat.

[moira]

Řekl bych, že o tomto tazatel ví. Ale hledá nějaký Swing aplikační framework, který mu usnadní navázání událostí na kontrolu podmínek a zpětně pak na změny v GUI. Je to právě o level výše než listenery na cokoliv. Bohužel sám bych občas něco takového potřeboval, takže netuším co použít...

[jehovista]

Presne tak, rekl jsi mozna o neco lepe to, co hledam(i kdyz sam presne nevim, co to je - jeste jsem se s nicim takovym nesetkal a to jsem toho uz v jave potkal docela dost).

[Filip Jirsák]

Řešil bych to pomocí binding knihovny – buď JGoodies Binding, případně Beans Binding (JSR 295). Osobně dávám přednost JGoodies Binding, ale JSR 295 bude standard (nevím ale, zda už je už použitelné v produkčním nasazení).

Vytvořím si pak nějaký řídící bean, který má (zpravidla logické) hodnoty pro různé stavy GUI, a podle těchto hodnot se pak zase řídí stav komponent. Takže bych měl třeba vlastnosti jmenoVyplněno a checkboxAktivní, které by se nastavovaly podle stavu GUI komponent. Podle třetí vlastnosti rozšířenéNastavení bych pak třeba řídil viditelnost/přístupnost comboboxu nebo dalších komponent. Uvnitř beanu pak mám logiku, která se vyvolá při každé změně prvních dvou vlastností, a která třetí vlastnost nastaví na true jedině v případě, kdy je jméno vyplněné a zároveň checkbox aktivní.

[jehovista]

Ja mel na mysli spis nejaky "pytel", kam bych nasypal vsechny properties(resp. bych tam odkazal vsechny event listenery z GUI) a pak pomoci nejakeho EL jazyka psat podminky. Vlastne ani sam nevim presne, co chci, jen jsem myslel ze treba nekoho napadne. Hlavni motivaci pro me je nevytvorit spagetovy kod.

[Filip Jirsák]

Podle mne ta beana a binding právě tohle splňuje. Jenom se ty podmínky nepíší v nějakém EL jazyce, ale normálně v Javě – na těch pár podmínek ale zase nemá smysl do toho tahat nějaký další jazyk. Chápu, že určit ty podmínky deklarativně by bylo efektnější, ale tohle zase člověka víc nutí zamyslet se nad stavy GUI. Pokud jsou ty stavy rozumně navržené, vede tohle řešení na rozumný kód. Pokud by mi to v té beaně vedlo na různé podivné kombinace stavů, je to pro mě signál, že nemám moc dobře rozmyšlené ty stavy GUI, a i když to takhle složitě naprogramuju, bude to stejně nepochopitelné pro uživatele.

[Mips]

S podobným problémem zkušenosti nemám, ale napadly mě dvě věci:

• Prolog
• něco podobného museli řešit tvůrci Excelu a dalších tabulkových editorů (změna téhle buňky způsobí změnu hodnot v těchto buňkách a jejich změny následně ještě v jiných buňkách, …)

[pht]

Zaroven potrebuju ohlidat, aby to fungovalo i naopak - nekde checkbox deselektuju a tim mi zmizi "constraint" jinde. Samozrejme neni problem ty podminky nabastlit do kazdeho controlleru, ale chtel bych to cele vyresit nejak elegantneji, aby se to cele dalo dobre menit/debuggovat/... a nechci znovu objevovat kolo.

To co chcete je Mediator pattern. Uděláte zvláštní objekt (mediator) který je zodpovědný za správné nastavení všech ostatních (do něj dáte tu logiku), a u všech ostatních si do ošetření události (např. kliknutí na tlačítko) dáte jen předání upozornění tomu mediátorovi.

[jehovista]

To bude asi ono, diky.

[Petr Masopust]

Mozna trochu velky kanon, ale pravdepodobne hledas neco jako Drools. Pripadne zkus nejaky jiny rule engine, s touhle oblasti konkretne moc zkusenosti nemam.

[Ladicek]

Před časem jsem narazil na dva články na tohle téma, jeden obecný a druhý právě s Drools.

[jehovista]

To vypada dost zajimave. jenom doufam, ze si s tim nenatahnu deset mega knihoven