Pokud vam nejaka cast tohoto navrhu prijde zvlast silena, jsem rad ze to krome pozdni denni ... no spis nocni doby muzu hodit i na zvysenou teplotu. A) Tentokrat jsem zacal tim ze jsem zacal rozmyslet jednotlive modely workflow. Seznam neni uplny, ale mel by zachytit vsechny vyrazne odlisne workflow. 1) Zadost o (vstupni, prvni) formular: Puvodni verze predpokladala ze uzivatel zavola formularnika, ten planovac, ktery z databaze spravnym dotazem vytahne strukturu (sablonu) formulare a necha formularnika podle teto sablony sestavit. V nove verzi, pokud jsem spravne pochopil, zaverecne sestavovani provede formularnik volanim XLST sablony s daty z databaze jako parametry. 2) Odeslani formulare: Zde se mysli predevsim kterykoliv z bibiliografickych formularu, ale stejny workflow bude mit napr. odeslani formulare modifikujiciho seznam kateder nebo casopisu. Zde formularnik prevezme data od uzivatele, podle informaci zakodovanych ve formulari (INPUT HIDDEN) je doplni do uplneho zaznamu (pochopitelne nektere informace se mohou doplnit na zaklade dalsiho pristupu do databaze, ale prijde mi ze se bez toho lze obejit), posle planovaci ktery se uz nebude muset zabyvat tim jaky konkretne to byl formular, ale bude mu stacit zakladni typ - napr vsechny bibiliograficke formulare by mohli byt reseny stejne. V dalsim kroku posle nezkontrolovany zaznam, prislusne oznacen, do databaze pro kazdy pripad. Potom zacne postupne provadet testy, pripadne predpripravi seznam testy a preda modulu tester (druha moznost postavena na miru rozdeleni planovace a testeru se vsemi testy na dva stroje, tester bude kazdopadne velmi primitivni pokud do nej nepocitame jednotlive testy). Vetsina testu bude spocivat v kontrole jedne polozky nebo skupiny polozek proti nejake tabulce s moznymi vysledky ano, ne, seznam podobnych moznosti. Po skonceni testu planovac odesle tyto vysledky (resp vysledky spolu s formularovymi daty) do databaze jako update predchoziho zaznamu, aby je nemusel provadet znova, a vrati formularnikovy ktery je nacpe do formulare a vrati uzivateli (formularnik by mohl mit poznamenano dost dat aby mohl zrekonstruovat formular bez dalsiho pristupu do databaze, nebo mu vysledek tohoto pristupu muze poslat planovac spolu s daty. Vlastni plneni formulare provede kazdopadne formularnik.) Poznamka: pro interni potreby programu - potvrzovani, zde zmineny update ... se vygeneruje jednoznacny klic i v pripade ze ho uzivatel nezada nebo zada nejednoznacny. Muzeme se rozhodnout ho uzivateli dat nebo ne, ale kazdopadne se muzeme spolehnout ze bez cut&paste si ho nezapamatuje. Poznamka 2: Jake klice vlastne uzivatele voli ? Slo by nejednoznacnost resit (zkusit resit) napr. pridanim jejich jmena ? Poznamka 3: Bibliograficke formulare budou chodit po jednom. Naopak modifikace seznamu kateder nebo schvalovani muze vest k nekolika zaznamum v jednom formulari. Myslim ze nejpozdeji planovac by mel provest rozdeleni. Poznamka 4: komunikace s databazi muze byt i nekolik dotazu po sobe. Zalezi na tom jak mnoho funkcnosti vrazime do databazoveho modulu. Vic nez jeden to ale bude v tomto pripade temer urcite. 3) Vyhledavani netrivialni neboli prave: Mysleno podle autora, casopisu, fulltext nebo jineho prirozeneho udaje. Bude probihat podobne jako odeslani formulare s vynechanim odeslani dat do databaze, tedy planovac nejprve kontaktuje tester aby overil smysl zadanych udaju (ovsem i v negativnim pripade vyhledavani provede. Treba dotazem na vsechny autory s titulem MgDr hledame chybne zaznamy ....) a pote provede dotaz do databaze ve forme podobne ukladani dat (databaze provede sice uplne jiny dotaz, nebot data nyni skonci ve WHERE misto v SET, ale to je vlastnost SQL. Umim si predstavit databazi ktera ma vkladani udaju a vyhledavani podle nich velmi podobne. Napriklad neco zalozene na echo a grep nebo na sedu.) Planovac pote vrati formularnikovy jak opraveny formular, tak vysledek hledani a formularnik ho vysype uzivateli podobne jako v predchozim pripade. Jedine formularnik vi, rozumej interpretuje prislusne pokyny, jestli vysledky budou aktivni (tedy budou obsahovat napr cudlik "podrobnosti", budou editovatelne ...) nebo pouze pasivni. 4) Vyhledavani trivialni neboli podle klice: Mysleno bud vyhledani zaznamu podle klice, nebo napriklad vyhledani podle vlajky "schvaleno zadavatelem" & not "schvaleno katedrou". Zde se vyuzije toho ze v techto udajich nejde udelat chybu (resp. jde, ale nejde ji opravit. Kdyz misto klice 1234 zadate 4321, je to chyba ale program nemuze udelat nic lepsiho nez prohlasit ze zaznam s klicem 4321 neexistuje. Nabizet podobne klice by bylo riskantni uz z bezpecnostnich duvodu, o tom jak je poznat nemluve.) Poznamka: schvaleno zadavatelem se mysli ze nam odsouhlasil vsechny opravy preklepu. Pokud je zaznam v poradku, predpokladame ze je schvaleny i kdyz ho uzivatel podruhe neodeslal, nebot on nemel duvod to delat. 5) Export: Uzivatel ve formulari zada kam si preje exportovat (muze mit jen jednu moznost, nebo treba select ...). Formularnik preda tento udaj, pripadne dalsi udaje (limitni datum) z formulare planovaci, ten je poznamena do databaze (pro cache, viz dale) a hodi exporteru, nebo nejprve provede vyhledavani takovych zaznamu (bude se patrne jednat o jednoduche vyhledavani - "schvaleno knihovnou" & "akademicky rok=..") a pote preda exporteru vysledek tohoto hledani spolu s udaji. V prvni variante pochopitelne prislusny select provede prislusny exportni modul, cimz se sice snizi cistota navrhu ale take spotreba kapacity site. Obecne navic muze dojit k usetreni databaze, nebot zatimco mnozinu zaznamu urcuje planovac, mnozina sloupcu zavisi na formatu exportu. Pravda, i tak to planovac muze udelat, ale opet tim snizi cistotu navrhu. Exporter vyplivne primo vysledny soubor, ktery sice fyzicky pujde zpet pres planovac a formularnik, ale ani jeden z nich ho nebude menit, a skonci tedy jako "Unknown MIME - save to disk ?" v uzivatelove prohlizeci (posychrujeme si to tim ze si prislusne MIME vymyslime, aby to nejaky presprilis aktivni nejmenovany explo ... browser neinterpretoval). Pokud bude mit aplikace nejaky zapisovatelny adresar, muze do nej prislusny export ulozit nebo ho ulozit do polozky typu blob v databazi. Planovac potom v pripade stejneho dotazu muze rovnou hodit tento nacacheovany soubor, pokud vi ze se mezitim nezmenili prislusna data (coz bude patrne hadat podle toho ze se nezmenili zadna data). Hlavnim duvodem tohoto kroku bude riziko ze si ten soubor nechaji vygenerovat dva lidi temer soucasne. Vlastne bychom meli chytat i situace kdy druhy pozadavek prijde pred ukoncenim prvniho, pokud bude export tak narocny. Poznamka: rozhodnuti kam ulozit vlastni soubor bych nechal na databazovem modulu. Informace o tom ze dany soubor existuje prijde kazdopadne do databaze a ne vsechny databaze budou disponovat datovym typem schopnym ulozit binarni soubor o velikosti ktera muze presahovat 1MB. 6) Import: Workflow importu/startovace bude stejne jako workflow odeslani formulare, jen misto formularnika bude importer/startovac. Maximalne muze dojit k odeslani vide bibliografickych formularu najednou. B) Poznamky k personalizaci Pokud skutecne zavedeme personalizaci, tedy predvyplneni urcitych polozek podle pocitace nebo na zaklade prihlaseni, bude to znamenat dalsi variantu mezi workflow 1 a 2. Formularnik posle soucasne s parametrem obsahujicim typ formulare i cookie a/nebo IP (aniz by vedel jestli je ta IP nejak dulezita), planovac provede dotaz do databaze na tuto kombinaci (nejobecneji "SELECT * from personalizace where (ip=$ip or skipip) and (cookie=$cookie or skipcookie)" ), provede predvyplneni formulare a v odpovedi formularnika upozorni aby je nezapomel do formulare vlozit stejne jako v pripade workflow 2. C) Poznamky k funkcnosti modulu Prestoze jeste nebyla rozdelena prace mezi jednotlive lidi, nejak jsem vycitil ze bude nejlepe kdyz si privlastnim SQL (a s nim databazi) dokud je volne. Do ostatnich modulu se radeji moc nepletu, tak jako tak nevim o XML dost na to abych je psal. Presto bych navrhl par pripominek k praci ostatnich, jaksi preventivne. Pokud o tom vedi, tim lepe. 1) Formularnik. Od zacatku by se melo myslet na to ze musi byt schopen doplnit do formulare udaje - nejcasteji do atributu value ruznych tagu input, ale take napriklad vysvetleni stavu do hlavicky nebo barevne zvyrazneni (ktere sice stejne nebude v nekterych prohlizecich videt, ale jina metoda krome rozhozeni layoutu me nenapada). 2) Importer. Na ucet tohoto modulu bych rad poznamenal ze ve vetsine pripadu nema smysl snaha o jakesi davkove zpracovani. Pozadavky na nas kladene bude patrne relativne snadne zpracovat a prakticky nemozne odlozit, vzhledem k tomu ze vetsinou potrebujeme vysledek zaslat uzivateli do toho sameho browseru ze ktereho odeslal dotaz. Jedinou vyjimkou je importer, program ktery nemusi byt spousten z webu (Ale muze. Patrne nedostaneme povoleni k pouziti metody PUT, ale neni problem s posilanim souboru pres POST.). Importer by mel tedy mit dost slusnosti aby volani planovace prolozil nekolika slofiky, tedy volanimi funkce sleep. I v pripade ze bude posilat vice pozadavku soucasne (Ma to cenu ? Usetrime sit. Cyklus provede planovac, tedy dva cykly. Akorat v databazi to bude driv, tedy verze bez kontroly.) je muze rozhodit do bloku, pokud jich bude opravdu mnoho, a dat si mezitim slofika. Jinak by mohl i jeden velky import slusne zatizit server a zabranit tim ostatnim uzivatelum se na nej dostat, zvlast pokud pujde "z blizka". Kdyz uvazime ze dlouha doba importu nikoho neprekvapi ... pochopitelne mnozstvi slusnosti by nastavoval superuzivatel podle vykonnosti serveru (tj. neco by si tipnul). 3) Komunikacni modul. Tento modul je snadne na navrhu prehlednout, prestoze se na nem vyskytuje. Neni totiz popsan, pouze znazornen carami. Bude soucasti vsech modulu ktere budou s jinym modulem komunikovat po siti a bude obsahovat ctyri casti: a) vytvoreni dotazu - tuto cast jsem uz v podstate napsal pod jmenem libhttp.php Chybi jen vytvoreni kryptografickeho souctu. Pochopitelne, mohli bychom ji prepsat do XML, ale jake by to melo vyhody ? Takto se drzime standardu ktery je skoro tak stary jako web a samotny interpret PHP nam pomuze v lusteni. Pochopitelne, je mozne ze nekdy bude prenaset i data ve formatu XML, ale ta budou vytvorena nekym jinym, nejcasteji casti c jineho modulu. Navic zatim to hrozi jen v jedne variante exportu. b) prevzeti dotazu - mela by byt trivialni, s vyjimkou overeni kryptografickeho souctu. c) vytvoreni odpovedi - prace pro XML. Slo by provest i jinak, napriklad PHP serializaci nebo opet podle standardu pro prenaseni POST, ale zde lze predpokladat ze budeme mit velkou hromadu dat a velmi netrivialni poneti o jeji strukture (totiz bude se jednat o vysledek databazoveho dotazu). Jiste, kdyz uz tento preklad budeme mit, pro jistotu bychom ho meli zpristupnit metode b nebo modulum ktere nekomunikuji pres sit. d) precteni odpovedi - prace pro XML (Komunikace mezi moduly A a B bude vypadat takto: Aa->Bb->Bc->Ad) Pochopitelne, v pripade ze budou vsechny moduly v jednom fyzickem programu, komunikace se provede primym volanim funkce (vstupniho bodu) a komunikacni modul nebude zapotrebi. Pokud budou nektere moduly spojene a jine ne, staci myslet na poznamku u bodu c. Zvlast je nutne myslet na moznost "zkratu" mezi d a c, dulezitou pro export a uzitecnou i v jinych situacich - tedy modul muze byt pozadan aby poslal pozadavek, ale misto vraceni vysledku v rozlustene podobe ho binarne bez modifikace okopiroval na standardni vystup (vcetne nekterych hlavicek). Je zajimave ze tento zkrat bude uplne bez prace fungovat v pripade ze moduly budou v jednom programu - modul proste nedostane nic a data pristanou na jeho standardnim vystupu proste proto ze je shodny se standardnim vystupem predchoziho modulu. 4) Debug logger. Tento modul neni pro zmenu na navrhu vubec. Jeho funkci bude v pripade ze bude zapojen (pri ostrem provozu uz nebude zapotrebi, to uz budeme predpokladat ze prace kterou odvadi ostatni loggery je dostatecna) logovat prime vstupy kazdeho modulu a pripadne dalsi kontrolni informace, a to primo do MySQL databaze (zde neni zapotrebi portabilita, ale snadnost napsani a odladeni) bez pouziti kterekoliv casti databazoveho modulu. V dusledku cacheovani ktere PHP provadi s nim sice bude sdilet fyzicke pripojeni k databazi, ale to by chovani aplikace nemelo ovlivnit. D) Interface Kazdy modul bude mit jedno vlastni interface kterym bude volan. Krome toho budou nektere moduly volat jine pomoci jejich interface. Prestoze fyzicka komunikace muze probihat jinak, interface muzeme vzdy navrhovat jako dve nebo rekneme ctyri asociativni pole - vstupni a vystupni, pripadne (vstupni a vystupni)x(ostatni data a databazova odpoved), jejichz prvky mohou byt prime hodnoty nebo stejneho typu (neomezena rekurze). Take mozna stoji za to upozornit ze na klici pro dany prvek muze, ale nemusi zalezet. Na poradi prvku by zalezet nemelo, pokud bude neco potreba setrizene budou podle toho vybrany klice. Vstup databazove odpovedi pripada v uvahu pouze u jedne ze dvou zminenych variant exportu. V pripade ostatnich dat nejcasteji na prvni urovni pole bude pole s konkretnimi klici a navrh interface bude prave seznam techto klicu a obsah odpovidajicich polozek. Obsah polozky pole s klicem "X" budeme dale nazyvat argumentem "X". Databazova data v XML odpovedi nepochybne pujde od ostatnich dat odlisit tim ze budou mit zcela odlisnou strukturu. V ostatnich jazycich bychom meli na vyber z mnoha moznosti a tato by mezi nimi patrne nebyla, ale v PHP na vyber nemame (poznamka: objekt nelze prenest po siti, asociativni pole ano). Vyjimkou bude rozhrani formularnika, importu a startovace. 1) Formularnik bude mit 3 nebo 4 vstupni pole - $_GET, $_POST, $_COOKIE a $_SYSTEM (pro detekci IP). Data v polich $_COOKIE a $_SYSTEM budou patrne pouzita pouze pro personalizaci, $_GET patrne pouze ve workflow 1, ostatni workflow budou prenasena pomoci $_POST. Take by slo pouzit $_SYSTEM['PATH_INFO'] pro workflow 1 misto nebo vedle $_GET, ale zda se ze v tomto pripade to krome faktu ze je to moje oblibena metoda nema zadnou vyhodu. Vystupnim rozhranim je HTML stranka. Narozdil od stranek puvodniho caddisu by patrne mohla byt XML-kompatibilni (nebo jak se jmenuje ten duvod proc se misto
pise
... no jeste to muze byt SGML). Neuskodila by ji ponekud vetsi hlavicka. 2) Importer bude mit jako vstup soubor, pripadne standardni vstup, ve formatu urcenem druhem importu. Pri spusteni z webu soubor uploadnuty uzivatelem. Jeho vystupem bude patrne neco jako "ukol splnen z %f procent" /"pri importu doslo k %li chybam a %lli warningum"/(null). 3) Startovac bude mit jako vstup mail. Obavam se ze nema logiku aby mel jakykoliv vystup. Jiste, mohl by poslat mail zpatky. Uzivatele by nas nepochybne hnali pote co jim prijde uz desata reakce "ve vasem postu doslo k warningu". Jiste, stacilo by kdyby na ni neodpovidali, ale ... Nyni bezna rozhrani, ktere jsou dulezitejsi nebot maji nas program na obou koncich. 4) Planovac Muze dostat v poli rovnou seznam vysledku z formulare nebo neco co je sice castecne predzpracovane ale vypada velmi podobne. Vetsinu veci co s daty muze delat formularnik muze udelat planovac taky. Pochopitelne, formularnik mu vse prestrka do jednoho pole, zahodi hodnoty ktere jsme nechteli (i kdyz nevim kdo a proc by nam je strkal), vyhodnoti vlajkove vybery (Uzivatel si vybira vlastnosti ktere maji jako hodnotu mocninu dvou. Vyhodnoceni je vlastne OR vsech odpovedi.) a mozna udela i neco dalsiho, ale porad to bude vypadat velmi podobne. Jeho vystupem je a) navod pro sestaveni stranky. Konecna verze bude ovlivnena tim co se bude jak dobre chroupat XLST sablone, ale v principu to bude posloupnost (tedy klice budou 0, 1, 2, 3, ...) instrukci typu "vyplivni INPUT typu HIDDEN s nazvem autor[]['pr'] a hodnotou 'Novak'". ( array("action"=>"input", "type"=>"hidden", "nazev"=>"autor[]['pr']", "value"=>"Novak") ) "ukonci tabulku" ( array("action"=>"table", "type"=>"end") ) "zmen barvu na error" ( array("action"=>"color", "type"=>"begin", "value"=>"error") ) "vypis komentar" ( array("action"=>"comment", "value"=>"
Zaznam pridan uspesne
") ) .... Posloupnost muze byt primo v poli nebo v argumentu BEGIN. b) soubor ktery se ma rovnou poslat uzivateli. Lze rozlisit podle interni promenne volajiciho nebo podle hlavicky. c) instrukce pro sestaveni stranky spojene s vysledkem SQL dotazu. V tom pripade budou misto jedne posloupnosti ctyri posloupnosti, v argumentech BEGIN, HEAD, RADEK, END. V poli HEAD muze byt obsah polozky value ne primo hodnota, ale nazev nebo cislo sloupce (nutno nejak odlisit), stejne tak v RADEK, rozdil je v tom ze v head se vytiskne nazev sloupce zatimco v radek hodnota. RADEK se provadi pro kazdy radek databazoveho vysledku. Tento vystup nastane obvykle pri hledani. 5) Export Predpokladam ze Export bude vice modulu - pro kazdy vystupni format jeden. Vstupem exportu muze byt bud omezovaci klauzule pro vyber zaznamu, pravdepodobne primo ve formatu podminky databaze, nebo primo vysledek prislusneho dotazu. V prvnim pripade exporter prida seznam polozek a posle databazi. Kazdopadne vysledek prevede do vysledneho formatu a vyhodi na vystup. 6) Sprava dat Rozhrani spravy dat, tedy high level rozhranni databaze, bude patrne vypadat velmi podobne jako low level, rozdilem bude vetsi abstraktnost. Misto pole jmen tabulek treba prijde obecnejsi cil, nektere cile budou rozbaleny na jednu tabulku nektere na vic, coz muze znamenat nutnost pri insertu/update rozdelit i data. Podobne seznam operaci bude zkraceny o nektere operace (hlavne v pripade triurovnove struktury, tedy obecna->relacni->MySQL databaze) a naopak jine, ktere bude nutno prekladat treba i na vice dotazu, pribudou. Primost dotazu - tedy napriklad jestli je nutne parsovat podminku a menit operace - muze byt zrejma z cile nebo treba z metody. Vystupem databaze pri operaci typu select bude vzdy tabulka, tedy seznam sloupcu a seznam zaznamu, kde zaznam je seznamem hodnot sloupcu. V poli doporucuji "sloupce"=>pole sloupcu "0"=> prvni radek "1"=> druhy radek ... Bude se ovsem jednat o databazovou odpoved, tedy zpusob konverze do XML by mohl byt jiny, efektivnejsi. Pokud to pujde samozrejme. 7) Tester Toto rozhranni je nejtezsi. Je mozne ze skoncime s tim ze kazdemu testu vnutime komplet informace co dostal planovac obohacene o vysledky jeho predchudcu, i kdyz to v mnoha pripadech bude hrube neefektivni. Alternativou je krome podmnoziny tehoz (pouze vybranne polozky, pole rozbaleny do vice testu) i obecnejsi navrh umoznujici mit obecny tester pro datum a zadavat mu meze ktere ma otestovat. Pokud bude spolecny tester (tedy tester bude nejen mnozina testovacich modulu, ale i nejaky spolecny kod), bude jeho ukolem prave z komplet informaci ktere dostal vybirat pro kazdy tester "tu jeho" cast. I kdyz i tester ve tvaru proste smycky pres vsechny testy muze byt uzitecny pro omezeni sitoveho provozu, pokud testy budou na jednom stroji s testerem a planovac na jinem.