Zobrazení pravidel v Knowledge Base

[vojir]

V rámci Mining UI by mělo být možné přepnout modul Rule Clipboard na "Knowledge base".

• [x] zobrazení pravidel bez ohledu na úlohu
• [x] "select" pro výběr Knowledge base, se kterou se má aktuálně pracovat (uživatel je bude moct přepínat)
• [x] jiné akce, než jsou u úloh v Rule Clipboard (testování klasifikačních modelů, export business rules)
• [x] nefunguje stránkování v rule clipboard (zároveň se někdy zobrazují míry zajímavosti někdy ne)
• [x] reload knowledge base při přidání pravidla z discovered rules
• [x] reload found rules, pokud uživatel odebere z knowledge base pravidlo, které je aktuálně zobrazené ve found rules

Návrh zobrazení:

[vojir]

Tak ještě trochu jinak - zobrazení aktuálního rulesetu (části knowledge base) pouze v podobě nadpisu + možnost změny rulesetu zobrazit jinde (např. v podobě "palety" pod "Data fields").

Konkrétní část knowledge base se bude používat také pro hodnocení pravidel, při přidávání pravidel atd. Při vytvoření nového mineru bude vytvořen nový ruleset, uživatel ale bude mít možnost vybrat některý již existující.

[PreVaDu]

Většinu mám již předchystanou, s výběrem jsem počítal a zobrazuje se tam momentálně "selectbox"... Když na to koukám, napadá mě, že bychom mohli taby neudělat stejně široké a tím získat více místa u Knowledge base a dát ten selectbox k němu, k tomu nadpisu... Byl by vidět vždy a dávalo by to smysl. Otázkou je, jak dlouhé názvy rulesetů asi tak budou (zda je omezíme, nebo ne). Předpokládám, že nebudou mít názvy úloh...

[PreVaDu]

Opět jsem pokročil... Původní představa se docela zkomplikovala, ale snad se blížíme cíli. Potřeboval bych:

• opravit rulesCount, které dostávám s pravidly v rulesetu, je vždy 1
• říct, jak má být provedeno přidání nového rulesetu?
• domluvit grafické detaily

[vojir]

• Změnit výpis možných rule setů ze selectu na výpis ve strong
• Odkaz "Add new ruleset" změnit na "Change rule set"
• Změna rule setu bude řešena v overlayi

[PreVaDu]

Provedl jsem většinu potřebných změn. Nyní lze rule set měnit atd. Chybí mi overlay pro změnu názvu a popisku + mazání rulesetu. Potřebuji

• id aktuálního rulesetu z configu (při načtení)
• předávat popis rulesetu spolu s rulesety při načítání listu
• při přidání rulesetu není kam předat popis (chybí parametr)
• opravit drobnou chybku v configu, poté by mělo být možné mazání z KB

Uvítám jakékoliv komentáře z testování.

[PreVaDu]

Dodělal jsem overlay pro změnu názvu (a popisku, až bude pro to podpora na straně serveru) + mazání. Zatím je overlay dostupný pouze při kliknutí na ikonku u názvu rulesetu v KB záložce (ikonka se nezobrazuje díky chybě oprávnění složky v images).

Momentálně nastavuji napevno ruleset, který bude vybrán po smazání toho aktuálního, ale který to má v praxi být? Ačkoliv by byl následný výběr v overlayi (change ruleset) asi vcelku praktický, má to dvě vady:

• uživatel může dát close a aplikace nemá s jakým rulesetem pracovat (momentálně počítá, že vždy nějaký je)
• dost by to opět překopalo logiku aplikace na straně KB, muselo by se počítat se stavem "žádný ruleset"

Až budou upraveny komunikace se serverem, zprovozním změny/přidání popisků a doladím případné chybky. Zatím stále KB pracuje jako pokročilejší MarkedTask pod MRManagerem, ale do budoucna to budu asi muset oddělit, jelikož začíná být těch podmínek příliš. Nelíbí se mi však to, že budeme muset ještě více duplikovat velmi podobné fce v painteru, listeneru apod. Není v Mootools možnost nějaké abstrakce, že bychom v FRManageru a MRManageru (a případně KBManageru v budoucnu) využívali většinu shodných funkcí z abstrakční vrstvy a upravili jen odlišnosti?

Ještě jedna drobnost - vím o chybě, že při změně rulesetu je třeba někdy kliknout vícekrát - z nepochopitelného důvodu není schopen (občas, bez rozpoznatelných shodností situací) Mootools vzít napoprvé atribut rel, ve kterém je uchováváno id rulesetu a někdy vrací null - pro stabilitu aplikace není v takovém případě nic provedeno a raději se čeká na další akci. Zkusím dát to id do adresy za # a brát to od tam, ale nevím, zda to pomůže...

[vojir]

Stav "žádný ruleset" uvažovat nebudeme, to tam raději nedávejme možnost smazat aktivní ruleset...

[PreVaDu]

Z tohoto hlediska mi připadá smysluplnější mazat kterýkoliv ruleset jen ne ten aktuální.

[vojir]

To by zas bylo matoucí... Raději nechejme to overlayové okno primárně pro změnu rulesetu, stejně bude muset ještě vzniknout jiné rozhraní pro správu rule setů... Takže mazání necháme asi na něj.

[PreVaDu]

Zrušil jsem možnost mazání. Správa rulesetů by klidně mohla být před načtením aplikace, aby to nekolidovalo. Jinak čekám na další úpravy a pokyny.

[vojir]

Bug: Aktuálně se v info o knowledge base nezobrazuje název, ale jen závorka s informací o počtu pravidel

[PreVaDu]

Máte na mysli pravý boxík? U mě je vše ok, není to tím, že nemáte žádný na začátku "přidělen"? Přišel JSON s informací o rulesetu korektně?

[vojir]

Problém byl způsoben tím, že u daného rulesetu byl uložen prázdný název.

[PreVaDu]

OK. Jak to mám ošetřit na frontendu?

[vojir]

• zkusme tam dát nějaký text ve smyslu "(ruleset without name)"
• jinak bych navrhoval nechat tučně jen název rulesetu, počet pravidel dát normálním písmem do dalšího řádku, bez závorky

[vojir]

Aktuálně jsem narazil ještě na chybu při přidání pravidla do knowledge base z found rules (při zobrazené rule clipboard)

[PreVaDu]

Hlášená chyba opravena, ale KB se nereloaduje, mám to nějak řešit, nebo to upravíte v FRManageru?

[PreVaDu]

KB se momentálně reloaduje při jakékoliv činnosti s MR nebo KB z FR, jelikož je vše voláno z jedné funkce. V budoucnu lze zvážit oddělení kvůli odlehčení, pokud by byly výkonostní problémy. Budeme nějak řešit promítnutí smazaného pravidla z KB v FR?

[vojir]

Ještě prosím do formuláře doplňte možnost "storno" (když si to uživatel rozmyslí, tak aby měl možnost daný formulář opět schovat). Díky :)

[PreVaDu]

Skoro bych řekl, že je to zbytečné, protože uživatel buď skryje celý overlay, nebo klikne na nějaký ruleset a tím ho skryje, ale přidal jsem ho. ;)

[vojir]

Ještě prosím doplňte reload found rules (respektive stačí překreslení příslušného jednoho pravidla) v situaci, kdy uživatel odebere z knowledge base pravidlo, které je zobrazeno ve found rules.

[PreVaDu]

Tady narážím na jeden problém - nikde neuchovávám informaci, že je pravidlo z aktuální úlohy. Dokonce je to tak, že pokud uživatel přidá pravidlo do Rule clipboard a pak ho přidá z found rules do KB nebo z rule clipboard do KB, tak se to na jednom nebo druhém místě neprojeví. Teď ještě koukám, že mi v MR nezůstává signalizace umístění pravidla v KB, tlačítka fungují, ale nejsou vidět, když jsou přidána.

Trochu se nám to motá. Možná by bylo lepší, kdyby byly pravidla entity, které by měli tři boolean hodnoty, zda jsou ve FR, MR nebo KB. A měli by své posluchače, kteří by se obvolávali v momentě změny stavu, kdekoliv. Ale to je docela velký zásah, chtělo by to potom předělat všechny task managery (MRManager a FRManager) tak, aby s nimi pracovali jako nezávislými objekty. A tím, že je při každém requestu vytváříme/mažeme z paměti, tak je to teď úplně celé jinak.

Zkusím to více promyslet, abychom jen nenabalovali další kód.

[PreVaDu]

S výše popsaným souvisí následující:

• FR jsou vždy unikátní task, takže se tam nemusí řešit zobrazení posledního stavu jako u MR
• MR nedostávají nikde (v JSONu) informaci o tom, zda jsou v KB a ve které (obecně pravidlo v tasku v MR neřeší stav KB, má linky pouze pro přidání pozitivního/negativního, ale nemá indikátor stavu)

Má-li si každé pravidlo tak hezky pamatovat KB i MR, jak je to u FR, tak je dle mého nezbytné to předělat úplně jinak. Protože kontrolovat při každé práci s KB, zda se pravidlo nachází i v MR nebo ve FR by dost zvýšilo náročnost. Ke všemu nám fakticky vznikají duplikáty objektů (pravidel), ačkoliv se v db jedná o ten samý řádek.

Je na zvážení, do jaké míry jsou náročnost na předělání žádoucí. Pochopitelně lze jít cestou reloadu FR "natvrdo" vždy a neřešit označení přítomnosti pravidla z MR v KB. Skutečně nevím...

[PreVaDu]

Nasadil jsem reload natvrdo a zjistil jsem, že "palec" signalizující přidání pravidla do KB v FR je jen dočasný, zmizí při každém reloadu tasku, takže i při práci s rule clipboard a třeba odebráním pravidla z aktuálního tasku. To jen potvrzuje co píši výše - musí se to pro takovou indikaci víceméně celé předělat, musí být entity pravidla, ty budou spravovány nějakým managerem, který o nich bude vědět, bude je roztřiďovat a zároveň bude schopen obvolat všechny tasky (found rules, rule clipboard, kb), které dané pravidlo obsahují. Takto vytvořené entity musí být všechny pravidla v rule clipboard a aktuálním kb a podle mě i v aktuálním mining tasku. Při změně mining tasku (změna výsledků) by mělo dojít k smazání nikde jinde nepoužívaných a vytvoření nových (pro úsporu paměti), stejně tak v KB, protože pravidlo může být třeba jen v KB a ne v rule clipboard. Pokud vyhodnotíme náročnost na paměť jako minoritní problém, můžeme to uchovávat stále. Tak jako tak mají pravidla vlastní unikátní ID, dle nich jsme schopni s nimi pracovat.

Tasky (aktuální, rule clipboard nebo kb) by pak dostávaly pouze odkazy na pravidla, takže dané pravidlo by existovalo pouze jednou.

V rámci takovédle úpravy by bylo možné sjednotit duplikované třídy při tvorbě MR z FR. Každopádně je to na větší diskusi a promyšlení celé úpravy do detailu.

[PreVaDu]

Upravil jsem reloady FR a MR dle domluvy.