Reakce na druhou sadu navrhu:

Misty se jedna o mozna hodne prisnou kritiku, doufam ze to nevezmete osobne. Ja zase zkusim nevzit osobne kritiku meho navrhu, ke ktere pri tak male shode musi dojit. V prvni rade jsem zvedavy na ty reakce typu "to prece neni XLST, ale ...".
U vsech navrhu jsem mel pocit ze v nich neni dost informaci. Predpokladam ze stejnou chybu ma ten muj, napriklad u kazdeho prikladu bych mohl navrhnout presne strukturu. Prislo mi ale ze by v ni bylo tolik chyb ze to nestoji za to.
To ze mam nejvic dat i presto ze setrim HTML samo o sobe moc neznamena.

XK3:

Stromovou strukturu jsem predpokladal. Pokud necekame na odpoved, znamena to ze nas nezajima, nikoliv ze se pro ni casem vratime.
Udaje typu "nekdo s neminimalnimi pravy je prihlasen" nelze z bezpecnostnich duvodu predavat pres uzivatele zadnym natolik statickym zpusobem, abychom se obesli bez databaze. Je nutne udrzovat minimalne zaznam o tom, ze jsme vydali urcity pristupovy klic - session-id napriklad, i kdyz internim session PHP bych se vyhnul - a po urcite dobe (od vydani nebo od posledniho pouziti) ho prohlasit za neplatny (a uklidit session). Tento pristup pouzivaji i diskusni servery, a myslim ze my budeme potrebovat vetsi bezpecnost. Obavam se ze zadny kryptograficky podpis neni dost ucinny v pripade ze si utocnik muze vybrat co podepise.
Pochopitelne kdyz uz mame v databazi toto session-id, muzeme k nemu pridat par vlastnosti ktere si chceme o uzivateli udrzovat. Osobne ovsem nemyslim ze by tento stav session byl tak rozsahly. Presto muzeme (mozna dokonce budeme muset) radu udaju poznamenavat ve formularich z duvodu rychlosti - nebo proto abychom po vytimeoutovani session mohli dat uzivateli moznost ji po novem zadani hesla obnovit.
K prilozenym scriptum:
- Testy nefunguji z prikazove radky ani z CGI - patrne chyba v chovani require_once, kdy se volany program nepocita jako uz vlozeny. Ovsem obavam se ze to budeme muset resit my a ne autori PHP ...
- Je pravda ze PHP casto staci jako zacatek kodu <?, ale doporucen je <?php s podpporou vzdy a kompatibilitou s XHTML at je to cokoliv.
- Zda se ze jejich funkci je co nejlepe zamaskovat ktere moduly jsou lokalni a ktere vzdalene. Pri primem pouziti ovsem neodvadi az tak dobru praci. Predpokladal bych ze modul bude jiny modul volat primo jmenem funkce (a nebude ZNAT jeho URL) a teprve tato funkce, pokud modul nebude skutecne pripojen, provede zabaleni pozadavku. To neznamena ze pri vytvareni techto funkci nakonec nepouzijeme podobny kod. Mimochodem, php umoznuje (minimalne pomoci eval) za behu vytvorit novou funkci.

XK4:

Pusobi na me lehce nedodelanym dojmem ... doufam ze muj navrh pusobi lepe.

Struktura formulare - stejne jako v mem navrhu navrhuje jmena polozek, bude nutne se dohodnout ktere budeme potrebovat a na jmene, ovsem adresace prvku formulare nazvem polozky mi prijde nevyhodna.
Na druhou stranu se pripojuji k navrhu aby bylo mozne s inputem predat i dalsi parametr (konfigurace kontrolniho pluginu ...), mozna i nekolik parametru. Formularnik by mel pro tuto polozku vytvorit input hidden a pri prijmu opet pridat k polozce. Je to dobry priklad toho ze navrh formulare by vlastne nemel byt 1:1 udaj-tag, i kdyz z meho navrhu to tak nevypada - tato moznost by byla spise pro reseni zridka nastavajicich situaci, casteji bychom meli spojovat jak to jen jde.
Export: jak propasovat data primo k uzivateli u prohlizece ? Jak asi prohlizeci cekajici na obsah souboru vnutit aby zobrazil obsah souboru ? Tedy chtel jsem rict kde je problem ?
Databaze: Navrh rozhrani mi prijde silne nedostatecny, nicmene potvrzuji a rozvijim nasledujici poznamky:
- Vzhledem ke zpusobu zapisu operaci jsou vyhodne operace s vice operandy - operace "in" tedy nesmi chybet, at uz ji databazovy program prelozi na dve porovnani nebo ne.
- Abstraktni operace lock, unlock (resp. spise lock(level), unlock(level)) pro update, podminky locked(level) pro hledani a dalsi, ktere budou prelozeny na bitovy test vlajek.
- metoda inicializace s parametry o jeji urovni (vse smaz a zacni znova, smaz/presun sber a zahaj novy rok ...)

MB1:

Zacina to spise o navrh ruznych workflow ... no, ja tak taky zacal. Navrh silne podcenuje dulezitost databaze - protoze se budeme snazit vetsinu veci delat co nejvice parametrizovane a protoze jedine misto kam ukladat parametry je databaze, bude nutne s ni komunikovat prakticky porad.
Formularnik a jednotlive formulare jsou diskutovany relativne podrobne, ostatni mene.
A ja si delal starosti ze jsem to odflaknul ...

OK1:

Tento navrh jde na vsechno z pohledu struktury XML dokumentu. Dobra, mozna jsem proti XML zaujaty, ale navrh pusobi dojmem jako by se mel pouzivat zpusob komunikace "Uloz XML dokument na FTP server a pockej si na XML dokument s odpovedi", ztizeny tim ze ten samy FTP server pouziva nekolik jinych projektu. Nejen ze takovou metodu komunikace nepouzivame, XML dokumenty pro interni komunikaci nebudou vubec ukladany na disk (pokud nam nekdo nebude sniffitovat komunikaci, a tomu prece praci zprijemnovat nechceme, nebo ano ?). Doufam ze presto bude mozne nektere navrhy pouzit. Pro pozadavky bych ale XML nepouzival.
Poznamky:

Vzhledem k tomu ze ke kazdemu volani patri i navrat, nebude nutna zdaleka tak slozita sprava toho kdo koho vola. Z meho navrhu workflow by dokonce vyplyvalo ze jedine databaze bude volana vice nez jednim modulem (to jak import napodobuje formularnika nepocitam, jedna se o stejnou funkci).
Je pravda ze se jedna o seznam formularu, ale myslim ze nazev form je dost zavadejici. Spise bych volil neco jako <link>. I kdyz samotne odliseni ze se jedna o volani jineho formulare muze byt uzitecne. Kazdopadne tag <forms> je nadbytecny.
XML se strukturou formulare naopak vypada ze neco postrada - napr. <value>. Jinak receno, navrh se venoval jen prvnimu odeslani formulare.
Planovac by mel ulozit co obdrzel nejen po testech, ale i pred nimi, o tom jsme se jiz bavili. Potom je take jasne ze jednoznacne ID se musi generovat v ramci prvni komunikace planovace s databazi.
Spravce dat v tomto pripade bude asi muset opravdu hadat kdo to po nem chtel. Planovac by mel dotaz formulovat trochu jinak nez jak ho dostal od formularnika. Neco jako array("method"=>"select","table"=>"pages", "podminka"=>array("tablename"=>"uvod")) nebo alespon array("method"=>"select", "table"=>"pages","tablename"=>"uvod").
Neni mi jasne proc by na formulare na hledani a na formulare na zaznamy neslo pouzit stejnou sablonu. Pokud XLST dokaze to co nam o ni bylo bajeno ...
Vysledek hledani je zhruba to co vrati spravce dat. Myslim ze planovac by to mel trochu upravit, protoze krome prosteho vypisu bude mit uzivatel napriklad u nekterych zaznamu moznost editace ... pochopitelne, muze to delat formularnik ale asi ne tou samou XLST sablonou. Krome toho, u tebe se planovac dost flaka ...
Pouzit "jiny sber" zni opravdu drsne, nicmene zakladni idea - moznost pouziti jedne funkce na primarni data i na pomocna - rozhodne stoji za pokus.
Superuzivatel by mel mit moznost poustet SQL dotazy. Pokud ti prijde ze nejlepsi zpusob jak mu to umoznit je PhpMyAdmin, dobra - zaclenime PhpMyAdmin do projektu. Predpokladam ze licence bude GPL a ze my se rovnez rozhodneme pro GPL. Jediny hacek je ze my bychom mozna potrebovali spis zpristupnit rozhrani spravce dat (hlavne low-level) nez primo cilovou databazi. Puvodni navrh nepredpokladal ze si budeme delat takovou hlavu s kompatibilitou.
Ano, pokud me ostatni presvedci ze i pro tento smer komunikace se ma pouzivat XML, neni duvod aby XML prijimane importerem z XML (budeme mit i jine importery) nebylo jeho podmnozinou. Pokud superuzivatel neco zmeni, patrne to nebude proto ze se nudil, ale protoze to bylo zapotrebi a drive funkcni XML tedy naprosto spravne vratime, nebot v novych podminkach neni platne.
Pro kohokoliv jineho nez anonymniho uzivatele pochopitelne potrebujem nejake informace. O IP ovsem pujde jen pri prihlaseni (a kdo vi jestli), dale bude stacit session-id. O kontrolu jestli obsahuje dostatecna prava se klidne muze postarat tester. (Priklad vysledku testu: pouzil jste neznamy titul, telefonni cislo nakladatelstvi neni cislo, neznam casopis "Jdi do pici", nechtel jste napsat "Mesicnik chovatelu opic" ? a nemate opravneni k uprave tohoto zaznamu ...)

OV1:

V navrhu chybi hromada <TR>. Links si to bere dost osobne ...
Jinak je to naprosto skvele prehledne, s uzitecnosti a mnozstvim obsahu je to horsi. Dale:

Databaze: Prijde mi ze funkce Login, Logout a IsLogged je moc vypichnuta - resil bych jako Get/PutData.
Select slouzi k vyhledavani, nemodifikuje data.
Planovac: Neni mi jasne proc byli zrovna tyhle funkce vypichnuty. Myslim ze ani zdaleka nepokryvaji vse co musi planovac umet.

Poznamky

Co me mezitim napadlo a jeste jsem nezapomel:

Bude se hodit metoda "selectfirst", i bezne vyhledavani by melo mit moznost zadat maximalni pocet zaznamu. Na druhou stranu myslim ze nebude nutne babrat se s "druhych 20 zaznamu". I kdyz hlavne zalezi na tom jaky komform poskytuje pri schvalovani zaznamu original caddis.
Znovu upozornuji ze instrukce pro sestavovani formulare by meli byt obecnejsi nez jak pusobil priklad v mem navrhu. Na druhou stranu ne vse pujde nacpat do parametru inputu. Napriklad i original caddis obsahuje alespon jednu tabulku. Muj navrh predpokladal ze formular bude urceny mnozinou zaznamu z tabulky s netrivialni strukturou. Alternativou je pochopitelne primo XML dokument ulozeny v tabulce s polozkami nazev, data. Nejsem si jisty ktera varianta bude vhodnejsi pro editaci.