Workflows verze 2 Typicke cinnosti uzivatelu A) Zadavani bibliografickych udaju Tuto cinnost budou provadet pouze autori. 1. Uzivatel vleze na zakladni stranku. Zakladni stranka je nejspis instance formularnika bez parametru urcujicich typ formulare nebo typ cinnosti. Formularnik na zaklade tohoto pozadavku zobrazi seznam relevantnich cinnosti(formularu), ktery obdrzi jako vysledek dotazu planovace. Tuto cast primo pokryva WF0. 2. Uzivatel vybere cinnost(formular). Formularnik dotazem na planovac zjisti schema formulare, ktery sestavi a zobrazi. Tuto cinnost pokryva WF1. 3. Uzivatel formular vyplni a odesle. Poznamka:Budeme potrebovat(umoznovat) vicekrokove vyplnovani formularu s prubeznou interakci systemu s uzivatelem? Tedy takove vyplnovani, ze se bude formular vyplnovat po castech a formular se bude menit podle udaju v predchozich castech. A budeme umoznovat (treba kvuli prehlednosti) vicekrokove vyplnovani formulare bez interakce? Tedy formular bude prubezne odesilan, ale nebude se menit. Formularnik preda data bezezmeny planovaci, vcetne pouziteho formulare. Vsechny zmeny dat bude provadet pouze planovac(mozna tester). Formularnik by mel slouzit pouze pro prezentaci dat a komunikaci s uzivatelem. Planovac data zpracuje a pokud byly v datech chyby vrati schema formulare(znovu) obohacene o jiz zadana data, pokud byla data v poradku vrati pouze "OK-data prijata". Tento krok se opakuje dokud jsou v datech chyby. B) Prihlaseni uzivatele Vicemene specialni pripad A. 1. Uzivatel vleze na zakladni stranku. 2. Vybere cinnost "LOGIN". Formularnik dotazem na planovac zjisti schema formulare, ktery sestavi a zobrazi. 3. Uzivatel zada jmeno a heslo a formular odesle. Formularnik preda data bezezmeny planovaci, vcetne pouziteho formulare. Planovac overi udaje dotazem na spravce dat, ktery v pripade platnych udaju vygeneruje SID. Tato identifikace je pote predana zpet formularnikovi. C) Import Vicemene stejne jako A. 1. Uzivatel vleze na zakladni stranku. Pripadne se zaloguje. 2. Uzivatel vybere cinnost "Import". Formularnik dotazem na planovac zjisti schema formulare, ktery sestavi a zobrazi. 3. Uzivatel zada vstupni soubor, typ a format importovanych dat. Formularnik preda data bezezmeny planovaci, vcetne informace, ze jde o import(pouzity formular). Planovac data zpracuje a vrati informaci o uspesnosti importu jednotlivych zaznamu a identifikacni cisla techto zaznamu pro pripad, ze by je uzivatel hledal a chtel opravit. Tento krok se narozdil od A neopakuje. D) Vyhledani zaznamu 1. Uzivatel vleze na zakladni stranku stejne jako v A. Formularnik na zaklade tohoto pozadavku zobrazi seznam relevantnich cinnosti(formularu), ktery obdrzi jako vysledek dotazu planovace. Tuto cast primo pokryva WF0. 2. Uzivatel vybere cinnost vyhledavani. Formularnik dotazem na planovac zjisti jake zaznamy je mozne vyhledavat(synovske cinnosti vyhledavani). Z nich sestavi seznam a umozni uzivateli vybrat si. Uzivatel pote vybere konkretni vyhledavani. Poznamka: Nejspis budeme potrebovat jakesi hierarchicke usporadani cinnosti, jinak by byl vyber cinnosti asi dost neprehledny. Dojde sice k drobnemu zesloziteni WF1-zadost o formular, ale uzivateli to zprijemni praci a zjednodusi orientaci. Tuto cinnost pokryva WF1. 3. Uzivatel vyplni polozky, podle kterych se ma vyhledavat a takto castecne vyplneny formular odesle. Formularnik preda data bezezmeny planovaci, vcetne pouziteho formulare. Planovac dotazem na spravce dat zjisti seznam odpovidajicich zaznamu a tento seznam vrati formularnikovi. Ten potom data zobrazi. Prava uzivatele na vyhledani dat bych resil uz na urovni databaze nebo v planovaci. E) Export Jedna se vlastne o jednoduche rozsireni D. 1. Uzivatel vleze na zakladni stranku stejne jako v A, pripadne se zaloguje. 2. Uzivatel vybere cinnost export. Formularnik dotazem na planovac zjisti jake zaznamy je mozne exportovat(synovske cinnosti exportu). Z nich sestavi seznam a umozni uzivateli vybrat si. Uzivatel pote vybere konkretni export. 3. Zde je potreba obohatit vyhledavani o metodu prezentace dat. Napriklad zobrazeni(pro klasicke vyhledavani), RIV(pro export do formatu pro RIV), XML(pro export do formatu XML), atd. Planovac by v tomto pripade po obdrzeni dat od spravce dat tato data predal modulu export(v pripade ze by neslo o metodu zobrazeni) a ten by provedl prevod do prislusneho formatu. Formularnik by v pripade jine metody prezentace nez zobrazeni nabidl obdrzena data ke stazeni. F) Oprava bibliografickych udaju Oprava se sklada z vyhledani zaznamu a zobrazeni jiz zadanych dat s moznosti editace a opakovaneho odeslani. Tedy se jedna o spojeni cinnosti D a A. 1. Uzivatel absolvuje vyhledani zaznamu(u) podle D s metodou prezentace zobrazenim. 2. Z nalezenych zaznamu uzivatel vybere ten co chce editovat(tlacitkem nebo linkem). Pokud je zaznam chranen klicem(rozumnej heslem) je potreba uzivatele pozadat o jeho zadani. 3. Uzivateli je zobrazen prislusny formular s jiz zadanymi daty a ocekava se jejich oprava, coz je bod 3) cinnosti A. G) Zadani pomocnych udaju 1. Uzivatel se musi zalogovat viz cinnost B. 2. Dalsi postup je identicky s A s tim,ze uzivatel vybere formular pro zadavani prislusnych udaju. H) Zmena pomocnych udaju 1. Uzivatel se musi zalogovat viz cinnost B. 2. Dalsi postup je identicky s F. I) Schvalovani zaznamu odpovednymi pracovniky V podstate by se mohlo jednat o opravu zaznamu s jinymi pravi. 1. Uzivatel se musi zalogovat viz cinnost B. 2. Dalsi postup je identicky s F s tim,ze opravnenemu pracovnikovi se zobrazi navic zaskrtavaci policka pro odsouhlaseni zaznamu. Pripadne se mu neumozni editace ostatnich udaju. J) Tvorba formularu Tato cinnost je hodne jina nez vsechny predchozi. Je potreba navrhnout soustavu formularu a cest mezi nimi pro dost rozmanitou a nepredikovatelnou cinnost uzivatele. 1. Prvni moznost je zadavani novych formularu importem. Potom je postup identicky jako u C. 2. Druhou moznosti je zadavani formulare pres HTTP rozhrani. Zde nejspis bude potreba vicekrokovy formular s prubeznou interakci s uzivatelem. Workflows Workflow vstup - WF0 Uzivatel posle HTTP request na stranku formularnika bez parametru identifikujicich formular. V tomto miste bude platny pouze pripadny parametr SID, ostatni parametry budou ignorovany nebo se bude jednat o jine workflow. Formularnik volanim funkce planovace GetForm s nulovym parametrem urcujicim podstrom a pripadne parametrem SID zjisti seznam relevantnich cinnosti(formularu). Poznamka: budeme potrebovat jakousi hierarchickou strukturu cinnosti(formularu)? Napriklad pod cinnosti vyhledavani by bylo vyhledavani lidi, anotaci, casopisu, ... a kazda podcinnost bude mit jiny formular. Formularnik tento seznam zobrazi. Workflow vyber formulare - WF1 Uzivatel posle HTTP request na stranku formularnika s parametrem identifikujicim formular(nebo skupinu formularu, pokud budeme pouzivat hierarchickou strukturu). Tento request posle uzivatel napriklad kliknutim na odkaz vygenerovany v predchozim workflow. Formularnik volanim funkce planovace GetForm(SID,FID0, kde SID je identifikace zalogovaneho uzivatele a FID je identifikace pozadovaneho formulare, zjisti schema formulare, pripadne seznam podcinnosti(podformularu). Planovac realizuje funkci GetForm dotazem na spravce dat (volanim funkce spravce dat GetForm se stejnymi parametry). Spravce dat zjisti vsechny pripustne formulare z databaze a zaroven overi moznost pristupu uzivatele k temo formularum. Planovac pote jeste procisti formulare na zaklade stavu sberu a vysledek odesle Formularnikovi. Formularnik rozhodne(asi podle hlavicky odpovedi) zda se jedna o seznam nebo o formular a vracena data zobrazi uzivateli. Pokud se jednalo o seznam bude se obycejne toto workflow opakovat znovu. Workflow zadani dat - WF2 Uzivatel vyplni formular (pravdepodobne ten co mu byl vygenerovan ve WF1) a odesle ho. Formularnik z priznaku, ze se jedna o zaslani dat pozna o ktere workflow se jedna a prevezme data. Formularnik data nijak nemeni pouze je prevede do formatu komunikace mezi moduly(anebo toto provede komunikacni vrstva) a volanim funkce SendForm(data,FID,SID) preda data planovaci. Planovac nejdrive overi platnost pristupu uzivatele se SID na formular FID. Pote planovac ulozi data do DB volanim funkce spravce dat store(data,FID,SID,key). Overeni FID-SID by se mozna mohlo nechat na DB, ktera by v pripade neplatnosti vratila chybu z funkce store, na druhou stranu pokud si to planovac overi sam (i kdyz treba zase dotazem do DB - nejspis) nemusi cekat na vysledek funkce store a ta muze bezet asynchrone. Funkce store take musi vratit klic zaznamu, pokud ji uz tento nebyl vnucen jako parametr(vnucen bude v pripade, ze zaznam neni ukladan poprve a klic uz mu byl urcen). Z hlediska asynchronosti funkce store by bylo potreba zvlastni mechanismus pro generovani klicu novym zaznamum a takto vygenerovany klic pokazde vnutit funkci store. Pote planovac v pripade potreby(tzn. zadavani a oprava dat) preda data testeru volanim funkce validate(data,FID). Nakonec data zpracuje sam planovac (viz WF2x) a vysledek vrati formularnikovi. Ten potom vysledek zobrazi uzivateli. Workflow zadavani & oprava dat - WF2a Zpracovani dat v pripade zadavani nebo opravy bibliografickych nebo jakychkoliv pomocnych udaju je vcelku trivialni. Planovac overi platnost akce vzhledem ke stavu sberu - to by vlastne mohl delat pred poslanim dat testeru, aby ho zbytecne nezatezoval, ale kvuli konzistenci odstavcu to uvadim zde. Nasledne ulozi zmeny provedene testerem do DB volanim funkce spravce dat store(data,FID,SID,key). Vysledky o cinnosti vsech modulu ktere volal sesumarizuje a vrati formularnikovi. Workflow import dat - WF2b Planovac overi pozadavek, "rozbali data" tedy rozdeli na opravdova data, format dat a typ dat a zavola funkci importeru importData(data,format,typ). Importer prevede data do spravneho formatu a bude "simulovat" odesilani jednotlivych pozadavku formularnikem. Tedy bude volat znovu planovac, cimz se "spusti nova instance" planovace. Vysledky odpovedi planovace bude shromazdovat, vybirat z nich jen potrebne informace a pak je jako celek odesle puvodnimu planovaci. Planovac vysledky importeru pouze preda formularnikovi. Druha moznost je, ze importer nebude simulovat chovani formularnika, ale chovani planovace, tedy ulozi data do DB, overi platnost pozadavku vzhledm ke stavu sberu, zavola tester, zpracuje data a sesumarizuje vysledky a shromazdi vysledky ze vsech dilcich operaci. Celkove vysledky pak vrati planovaci. Pri sikovne implementaci druhe varianty (napriklad volanim pomocnych funkci planovace - tedy pro overeni platnosti pozadavku vzhledem ke stavu sberu se zavola funkce planovace, stejne tak se zpracovanim dat) jiste usetrime nejaka volani funkci a prenosy dat (zejmena prenos vysledku zadavani dat -cely formular s jiz zadanymi daty- zpet od planovace k importeru i kdyz nas zajima pouze klic zaznamu a pocet chyb), ale za toto usetreni zaplatime prehlednosti prehlednosti a zaprenim "logiky problemu". Navic kdyz budou vsechny zucastnene moduly na stejnem stroji bude usetreni male. Workflow vyhledani & export dat - WF2c V pripade exportu dat by mel za planovac vetsinu prace vykonat samostatny modul export. Tedy planovac overi pozadavek, "rozbali" prichozi data - tedy zjisti(vytvori dotaz pro exporter), ktere polozky se maji vyhledavat a pozadovany format dat. dotaz pro exporter by mel byt, z ryze praktickych duvodu, stejny jako dotaz pro spravce dat. Na zaklade pozadovaneho formatu zjisti, jestli se jedna o vyhledavani - v tom pripade zavola funkci spravce dat GetData(dotaz,SID) a vysledek vrati formularnikovi. Pokud se jedna o export zavola funkci modulu export exportData(dotaz,format,SID) a modul exporter se postara o zbytek. Tedy modul exporter zavola funkci spravce dat GetData(dotaz,SID), vysledek prevede do pozadovaneho formatu a vysledek vrati planovaci. Prevod do pozadovaneho formatu bude pravdepodobne probihat xsl transformaci - cinnost modulu export se potom bude sestavat pouze ze zjisteni, kterou sablonu je potreba pouzit pro pozadovany format. Interfaces Interface jednotlivych modulu bude volani funkci uvedenych v textu vyse. Volanim funkce se v tomto pripade mysli volani funkce jakesi transportni vrstvy, kterou kazdy modul "podstci" ostatnim modulum pro komunikaci s sebou. Transportni vrstva by mela oplyvat stejnymi funkcemi jako modul a navic jeste nekolika variantami pro kazdou z funkci (prozatim asi jenom varianta pro predavani dat formou asociativniho pole a formou XML dokumentu). Parametry funkci uvedenych vyse jsou az na parametr data parametry obsahujici nejaky (nejlepsi bude asi ciselny) identifikator a parametr data jsou nejak ulozena strukturovana data. spis jako reakce na Honzuv navrh: Rozhrani testeru bych pojal uplne jednoduse. Tester obdrzi data a popis formulare (pripadne identifikaci formulare a formular si nacte). Vsechny omezujici podminky budou jiz soucasti formulare (fyzicky mohou byt zvlast, kvuli usetreni prenosu techto informaci k formularnikovi, ale logicky budou tvorit celek). Coz samozrejme neni reseni problemu, ale pouze jeho odsunuti o kousek dal. Omezujici podminky by mohly mit tvar jakychsi podminek z SQL dotazu -tedy pouziti operatoru IN a EXIST, operatoru porovnani a logickych spojek AND a OR. Takto navrzene omezujici podminky snad nebude tak slozite vyhodnotit, akorat pro uzivatele bude mozna trochu nepohodlne tyto podminky zapsat (vlastne by to ani tak slozite byt nemuselo - pomoci nejakeho HTTP formulare)