Tuto činnost budou provádět pouze autoři.
Uživatel vleze na základní stránku. Základní stránka je nejspíš instance formulářníka bez parametrů určujících typ formuláře nebo typ činnosti. Formulářník na základě tohoto požadavku zobrazí seznam relevantních činností(formulářů), který obdrží jako výsledek dotazu plánovače. Tuto část přímo pokrývá WF0.
Uživatel vybere činnost(formulář). Formulářník dotazem na plánovač zjistí schéma formuláře, který sestaví a zobrazí. Tuto činnost pokrývá WF1.
Uživatel formulář vyplní a odešle.
Poznámka:Budeme potřebovat(umožňovat) vícekrokové vyplňování formulářů s průběžnou interakcí
systému s uživatelem? Tedy takové vyplňování, že se bude formulář vyplňovat po částech a formulář se
bude měnit podle údajů v předchozích částech. A budeme umožňovat (třeba kvůli přehlednosti) vícekrokové
vyplňování formuláře bez interakce? Tedy formulář bude průběžně odesílán, ale nebude se měnit.
Formulářník předá data bezezměny plánovači, včetně použitého formuláře. Všechny změny dat bude provádět
pouze plánovač(možná tester). Formulářník by měl sloužit pouze pro prezentaci dat a komunikaci
s uživatelem. Plánovač data zpracuje a pokud byly v datech chyby vrátí schéma formuláře(znovu)
obohacené o již zadaná data, pokud byla data v pořádku vrátí pouze "OK-data přijata". Tento krok
se opakuje dokud jsou v datech chyby.
Víceméně speciální případ A.
Uživatel vleze na základní stránku.
Vybere činnost "LOGIN". Formulářník dotazem na plánovač zjistí schéma formuláře, který sestaví a zobrazí.
Uživatel zadá jméno a heslo a formulář odešle.
Formulářník předá data bezezměny plánovači, včetně použitého formuláře. Plánovač ověří údaje
dotazem na správce dat, který v případě platných údajů vygeneruje SID. Tato identifikace je poté
předána zpět formulářníkovi.
Víceméně stejné jako A.
Uživatel vleze na základní stránku. Případně se zaloguje.
Uživatel vybere činnost "Import". Formulářník dotazem na plánovač zjistí schéma formuláře, který sestaví a zobrazí.
Uživatel zadá vstupní soubor, typ a formát importovaných dat. Formulářník předá data bezezměny plánovači, včetně informace, že jde o import(použitý formulář). Plánovač data zpracuje a vrátí informaci o úspěšnosti importu jednotlivých záznamů a identifikační čísla těchto záznamů pro případ, že by je uživatel hledal a chtěl opravit. Tento krok se narozdíl od A neopakuje.
Uživatel vleze na základní stránku stejně jako v A. Formulářník na základě tohoto požadavku zobrazí seznam relevantních činností(formulářů), který obdrží jako výsledek dotazu plánovače. Tuto část přímo pokrývá WF0.
Uživatel vybere činnost vyhledávání. Formulářník dotazem na plánovač zjistí jaké záznamy
je možné vyhledávat(synovské činnosti vyhledávání). Z nich sestaví seznam a umožní uživateli vybrat si.
Uživatel poté vybere konkrétní vyhledávání.
Poznámka: Nejspíš budeme potřebovat jakési hierarchické uspořádání činností, jinak by
byl výběr činnosti asi dost nepřehledný. Dojde sice k drobnému zesložitění WF1-žádost o formulář,
ale uživateli to zpříjemní práci a zjednoduší orientaci.
Tuto činnost pokrývá WF1.
Uživatel vyplní položky, podle kterých se má vyhledávat a takto částečně vyplněný formulář odešle. Formulářník předá data bezezměny plánovači, včetně použitého formuláře. Plánovač dotazem na správce dat zjistí seznam odpovídajících záznamů a tento seznam vráti formulářníkovi. Ten potom data zobrazí. Práva uživatele na vyhledání dat bych resil uz na úrovni databáze nebo v plánovači.
Jedná se vlastně o jednoduché rozšíření D.
Uživatel vleze na základní stránku stejně jako v A, případně se zaloguje.
Uživatel vybere činnost export. Formulářník dotazem na plánovač zjistí jaké záznamy je možné exportovat(synovské činnosti exportu). Z nich sestaví seznam a umožní uživateli vybrat si. Uživatel poté vybere konkrétní export.
Zde je potřeba obohatit vyhledávání o metodu prezentace dat. Například zobrazení(pro klasické vyhledávání), RIV(pro export do formátu pro RIV), XML(pro export do formátu XML), atd. Plánovač by v tomto případě po obdržení dat od správce dat tato data předal modulu export(v případě že by nešlo o metodu zobrazení) a ten by provedl převod do příslušného formátu. Formulářník by v případě jiné metody prezentace než zobrazení nabídl obdržená data ke stažení.
Oprava se skládá z vyhledání záznamu a zobrazení již zadaných dat s možností editace a opakovaného odeslání. Tedy se jedná o spojení činností D a A.
Uživatel absolvuje vyhledání záznamu(ů) podle D s metodou prezentace zobrazením.
Z nalezených záznamů uživatel vybere ten co chce editovat(tlačítkem nebo linkem). Pokud je záznam chráněn klíčem(rozumněj heslem) je potřeba uživatele požádat o jeho zadání.
Uživateli je zobrazen příslušný formulář s již zadanými daty a očekává se jejich oprava, což je bod 3) činnosti A.
Uživatel se musí zalogovat viz činnost B.
Další postup je identický s A s tím,že uživatel vybere formulář pro zadávání příslušných údajů.
Uživatel se musí zalogovat viz činnost B.
Další postup je identický s F.
V podstatě by se mohlo jednat o opravu záznamu s jinými právi.
Uživatel se musí zalogovat viz činnost B.
Další postup je identický s F s tím,že oprávněnému pracovníkovi se zobrazí navíc zaškrtávací políčka pro odsouhlasení záznamu. Případně se mu neumožní editace ostatních údajů.
Tato činnost je hodně jiná než všechny předchozí. Je potřeba navrhnout soustavu formulářů a cest mezi nimi pro dost rozmanitou a nepredikovatelnou činnost uživatele.
První možnost je zadávání nových formulářů importem. Potom je postup identický jako u C.
Druhou možností je zadávání formuláře přes HTTP rozhraní. Zde nejspíš bude potřeba vícekrokový formulář s průběžnou interakcí s uživatelem.
Uživatel pošle HTTP request na stránku formulářníka bez parametrů identifikujících formulář.
V tomto místě bude platný pouze případný parametr SID, ostatní parametry budou ignorovány nebo
se bude jednat o jiné workflow. Formulářník voláním funkce plánovače GetForm s nulovým parametrem
určujícím podstrom a případně parametrem SID zjistí seznam relevantních činností(formulářů).
Poznámka: budeme potřebovat jakousi hierarchickou strukturu činností(formulářů)? Například
pod činností vyhledávání by bylo vyhledávání lidí, anotací, časopisů, ... a každá podčinnost bude
mít jiný formulář.
Formulářník tento seznam zobrazí.
Uživatel pošle HTTP request na stránku formulářníka s parametrem identifikujícím formulář(nebo skupinu formulářů, pokud budeme používat hierarchickou strukturu). Tento request pošle uživatel například kliknutím na odkaz vygenerovaný v předchozím workflow. Formulářník voláním funkce plánovače GetForm(SID,FID0, kde SID je identifikace zalogovaneho uživatele a FID je identifikace požadovaného formuláře, zjistí schéma formuláře, případně seznam podčinností(podformulářů). Plánovač realizuje funkci GetForm dotazem na správce dat (voláním funkce správce dat GetForm se stejnými parametry). Správce dat zjistí všechny přípustné formuláře z databáze a zároveň ověří možnost přístupu uživatele k těmo formulářům. Plánovač poté ještě pročistí formuláře na základě stavu sběru a výsledek odešle Formulářníkovi. Formulářník rozhodne(asi podle hlavičky odpovědi) zda se jedná o seznam nebo o formulář a vrácená data zobrazí uživateli. Pokud se jednalo o seznam bude se obyčejně toto workflow opakovat znovu.
Uživatel vyplní formulář (pravděpodobně ten co mu byl vygenerován ve WF1) a odešle ho. Formulářník z příznaku, že se jedná o zaslání dat pozná o které workflow se jedná a převezme data. Formulářník data nijak nemění pouze je převede do formátu komunikace mezi moduly(anebo toto provede komunikační vrstva) a voláním funkce SendForm(data,FID,SID) předá data plánovači. Plánovač nejdříve ověří platnost přístupu uživatele se SID na formulář FID. Poté plánovač uloží data do DB voláním funkce správce dat store(data,FID,SID,key). Ověření FID-SID by se možná mohlo nechat na DB, která by v případě neplatnosti vrátila chybu z funkce store, na druhou stranu pokud si to plánovač ověří sám (i když třeba zase dotazem do DB - nejspíš) nemusí čekat na výsledek funkce store a ta může běžet asynchroně. Funkce store také musí vrátit klíč záznamu, pokud ji už tento nebyl vnucen jako parametr(vnucen bude v připadě, že záznam neni ukládán poprvé a klíč už mu byl určen). Z hlediska asynchronosti funkce store by bylo potřeba zvláštní mechanismus pro generování klíčů novým záznamům a takto vygenerovaný klíč pokaždé vnutit funkci store. Poté plánovač v případě potřeby(tzn. zadávání a oprava dat) předá data testeru voláním funkce validate(data,FID). Nakonec data zpracuje sám plánovač (viz WF2x) a výsledek vrátí formulářníkovi. Ten potom výsledek zobrazí uživateli.
Zpracování dat v případě zadávání nebo opravy bibliografických nebo jakýchkoliv pomocných údajů je vcelku triviální. Plánovač ověří platnost akce vzhledem ke stavu sběru - to by vlastně mohl dělat před posláním dat testeru, aby ho zbytečně nezatěžoval, ale kvůli konzistenci odstavců to uvádím zde. Následně uloží změny provedené testerem do DB voláním funkce správce dat store(data,FID,SID,key). Výsledky o činnosti všech modulů které volal sesumarizuje a vrátí formulářníkovi.
Plánovač ověří požadavek, "rozbalí data" tedy rozdělí na opravdová data, formát dat a typ dat a zavolá funkci importeru importData(data,format,typ). Importer převede data do správného formátu a bude "simulovat" odesílání jednotlivých požadavků formulářníkem. Tedy bude volat znovu plánovač, čímž se "spustí nová instance" plánovače. Výsledky odpovědí plánovače bude shromažďovat, vybírat z nich jen potřebné informace a pak je jako celek odešle původnímu plánovači. Plánovač výsledky importéru pouze předá formulářníkovi. Druhá možnost je, že importér nebude simulovat chování formulářníka, ale chování plánovače, tedy uloží data do DB, ověří platnost požadavku vzhledm ke stavu sběru, zavolá tester, zpracuje data a sesumarizuje výsledky a shromáždí výsledky ze všech dílčích operací. Celkové výsledky pak vrátí plánovači. Při šikovné implementaci druhé varianty (například voláním pomocných funkcí plánovače - tedy pro ověření platnosti požadavku vzhledem ke stavu sběru se zavolá funkce plánovače, stejně tak se zpracováním dat) jistě ušetříme nějaká volání funkcí a přenosy dat (zejména přenos výsledků zadávání dat -celý formulář s již zadanými daty- zpět od plánovače k importéru i když nás zajímá pouze klíč záznamu a počet chyb), ale za toto ušetření zaplatíme přehledností přehledností a zapřením "logiky problému". Navíc když budou všechny zůčastněné moduly na stejném stroji bude ušetření malé.
V případě exportu dat by měl za plánovač většinu práce vykonat samostatný modul export. Tedy plánovač ověří požadavek, "rozbalí" příchozí data - tedy zjistí(vytvoří dotaz pro exporter), které položky se mají vyhledávat a požadovaný formát dat. dotaz pro exporter by měl být, z ryze praktických důvodů, stejný jako dotaz pro správce dat. Na základě požadovaného formátu zjistí, jestli se jedná o vyhledávání - v tom případě zavolá funkci správce dat GetData(dotaz,SID) a výsledek vrátí formulářníkovi. Pokud se jedná o export zavolá funkci modulu export exportData(dotaz,format,SID) a modul exporter se postará o zbytek. Tedy modul exporter zavolá funkci správce dat GetData(dotaz,SID), výsledek převede do požadovaného formátu a výsledek vrátí plánovači. Převod do požadovaného formátu bude pravděpodobně probíhat xsl transformací - činnost modulu export se potom bude sestávat pouze ze zjištění, kterou šablonu je potřeba použít pro požadovaný formát.
Interface jednotlivych modulu bude volání funkcí uvedených v textu výše. Voláním funkce se v tomto
případě myslí volání funkce jakési transportní vrstvy, kterou každý modul "podstčí" ostatním modulům
pro komunikaci s sebou. Transportní vrstva by měla oplývat stejnými funkcemi jako modul a navíc ještě
několika variantami pro každou z funkcí (prozatím asi jenom varianta pro předávání dat formou
asociativního pole a formou XML dokumentu). Parametry funkci uvedených výše jsou až na parametr data
parametry obsahující nějaký (nejlepší bude asi číselný) identifikátor a parametr data jsou nějak
uložená strukturovaná data.
spíš jako reakce na Honzův návrh: Rozhraní testeru bych pojal úplně jednoduše. Tester
obdrží data a popis formuláře (případně identifikaci formuláře a formulář si načte).
Všechny omezující podmínky budou již součástí formuláře (fyzicky mohou být zvlášť, kvůli ušetření přenosu
těchto informací k formulářníkovi, ale logicky budou tvořit celek). Což samozřejmě není řešení problému,
ale pouze jeho odsunutí o kousek dál. Omezující podmínky by mohly mít tvar jakýchsi podmínek z SQL dotazů
-tedy použití operátorů IN a EXIST, operátorů porovnání a logických spojek AND a OR. Takto navržené
omezující podmínky snad nebude tak složité vyhodnotit, akorát pro uživatele bude možná trochu nepohodlné
tyto podmínky zapsat (vlastně by to ani tak složité být nemuselo - pomocí nějakého HTTP formuláře)