Slovnik ------- App = aplikace, fyzicka - kus kodu, neco delajici, typicky virtualni host a podobne (vice app=apps) Appz = system, sdruzujici app nebo apps do nejakeho celku, ktery se pak v ramci systemu nejak chova (uctuje, loguje, ....) Appz ---- Aby system mohl nejak rozlisovat 'to co bezi' a implementovat rozumne spolecny login, je nutne rozsirit core o logickou aplikci (appz). Aplikace defacto znamena, ze system vnima zacatek a konec nejake konkretni cinosti v ramci systemu - praci s aplikaci. Aplikace je ciste logicke deleni, spotrebovavane zdroje v ramci system (napr. templaty v ramci webu) mohou byt soucasti nekolika aplikaci. Samotny kod, ktery slouzi k provadeni cinnosti nemusi (ale muze) rozlisovat aktualni aplikaci. Obecne aplikace vyuziva systemove zdroje a muze byt spustena v ramci ruznych provadecich typu. Aktualne zaklade execution type jest 'www' modul a jeho virtualni web. Samotne CBS pobezi mimo aplikace z duvodu reseni problemu slepice a vajicka. Notabene uprava CBS aby bylo pouzitelne pro BFU by znamenala dost podstatne zmeny templat a celkove navigace. A neda se predpokladat, ze by na to mel nekdo v dohledne dobe cas. Samotna aplikace muze byt clenena na logicke casti, ktere jsou podobne ACL, avsak funguji mimo ACL. Resp. nad nimi. To znamena, ze aby mel uzivatel moznost nejake konkretni akce, musi mit vsechan pristupna ACL *a navic* jeste musi byt povolen pristup k temto logickym castem. Tyto logicke casti budiz nazyvany 'fearure'. Tyu jsou, spolu s ostatnima vlastnostma, exportovany konkretni provadecem (execution type - ET). Featury nebudou implementovany jakozto ACL protoze: - zmeny featur budou probihat z neprivilegovanych uctu - system by musel principielne umet menit ACL i z beznych uctu, coz neni uplne dobre - pokud by featury byly ACL a nebylo pritomto tak app netusi, jesli data vec v system proste neni nebo je neaktivni (neni zaplaceno) - kazda ACL by musely mit krom zakladnich deny/allow mit rovne deny/disable/allow kde disable by byl 'treti' stav - testovani na urovni kodu musi rozlisovat, jesli se jedna o ACL nebo 'featuru', protoze pokud se nesplni ACL tak se proste zobrazuje genericka chyba - app nema moznost tuto skutecnost jakkoliv zmenit, kdezto v pripade proapdnuti featury app zobrazi 'kup si mne' - narozdil od ACL jsou featury 'zapinany' nestaticky - pri odcerpani kredity, nebo konci zkusebniho obdobi, nebo vyprseni trialu (zkus si mne na 24 let zadarmo) Featury tedy exportuje samotny ET a v ramci appz nastaveni, lze tuto featury zapinat/povolovat na zaklade eventu. Aby nebyly featury zavisle na konkretnim typu plateb (kredity, zasluhy, cas, ...) tak kazda feature muze byt zapnuta z ruznych 'zdroju'. Jakmile nejaky zdroj zapne danou featuru, je proste povolena. Pokud zadny zdroj nezapne - featura je disabled. V tomto pripade ma app moznost testovat 'posledni' zdroj, ktery vyprsel a podle jeho typu, zobrazit prislusny postup. Typicky kdyz bude posledni platny zdroj 'credit' -> zaplat. Pokud to bude 'time_trial' -> vyprselo obdobi, kdyz nas ohodnotite a napisete feedback, mate jeste neco navic, ... Co ja vim. Kazda generalni akce v ramci app bude logovana. Spusteni, ukonceni a pod. Nebudou se logovat jednotlive pristupy, bude se tedy jedna o generalni log, ze ktere se bude dolovat cas v app a pod. Tento log bude sdilen s prihlasovanim, bude se tedy jednat o takovy 'system log', ne moc podrobny, aby nezatezoval syste/DB, ale umoznoval nejake rozumne statistikovani. Pro stats v ramci systemu, jeho pouzivani, klikani je k dispozici klasicky log, ikdyz ho malokdo pouziva (www modul na to ma prikazy). Klasicky apache log nedokaze vytahnout sesny/vars, takze neni mozne koukat 'co/kdo' dela(l). WWW modul --------- Jakozto jediny ET bude aktualne slouzit WWW modul. Jeho upravy budou nasledujici: - presune se definice ACL z module info primo do WWW modulu, do settings, tam kam patri (aktualne existuje 78 ruznych ACL, rada z nich je jiz nevyuzivana) - do settings se prida definice exportu features - pribude volba, zda dany host bezi v ramci appz nebo samostatne - tato volba bude nejspise vylucna (tehnicke duvody, nevim, jestli rozumne pujde udelat obojetne) - budou pridany 'specialni' templaty, slouzici k ucelu appz (viz nize) a rovnou i generickych chyb (not found, access denied a pod) - tj. host bude moci genericky zobrazovat chyby a nebude se poustet silena CBS error stranka Prida se rada prikazu appz.* ktera bude umoznovat nasledujci: - enum appz - testovat stav aplikaci (bezi/nebezi) a aktualni - dotazovat se na featury - prepinat na jinou app Appz budou respektovat normalni URL settings. Nicmene, vice hostu muze sdilet stejnou URL a to tak, ze v pripade aktiave prislusne APP se requesty budou predavat na patricneho hosta. Takze oba pobezi, z jejich pohledu, na stejne URL. Pokud se pristoupi na virtual, ktery nebezi v ramci appz, proste se pusti jako normalne. Bude dokonce sdilet stejneho usera. Pokud host bude 'appz enabled' tak nastane vyse pospane spusteni prislusne aplikace. Host, bezici jako app enabled si muze nastavit specialni templatu, ktera bude spoustena (nevizualne!!!) pri danych akcich, ala spusteni, vypnuti, .... Features -------- Jak jiz bylo receno, ET exportuje features, tj. low level moznosti app. V ramci features by dana ap *nemela* brat na zretel 'zamer' vysledku, ale opravdu logicky clenit aplikaci z pohledu funkcnosti. Nexportovat prislis zgrupovane featury pod jednou, protoze tak znelo zadani, ale klidne rozdelit zadani na logicke casti, ktere poslese se zgrupuji na uroven pozadovaneho zadani. Features by tedy meli respektovat prirozenost aplikace, nikoliv pozadavky businesu. Pozadavky businesu by se meli plnit prave grupovanim. Pro udrzbu a vytvareni bude takovato struktura jednodussi, protoze features jsou v zasade hardcoded (logicky) a rozese spoustou kodu, casto i ruznymy jazyky (js, php, cecko, ...) - takze v tomto ohledu je na prvnim miste udrzitelnost. Sestava ruznych 'features' (jejich set) tvori logicky celek feature set. Feature set muze byt zapnut/vypnut. Kazda appz muze mit vice feature setu, ktere se mohou aktivovat nevisle. Protoze aktualne neni jasno, jak system aktivaci bude fungovat, nebo jesli bude vice soubeznych systemu (na ruzne appz), tak jich z principu bude proste vice. Kazdy 'typ' aktivace bude samostatny. Vysledek je (jak jiz bylo vise uvedeno) prosty OR. Aktivace featur bude na zacatku probihat pouze casove a kreditove. Kredit bude asi spise jen na testovani, ale bude vhodne mit od zacatku 2 typy, pokud nebude naprosto jasne, ze to bude fungovat pouze JEDNIM zpusobem. Kredit klasika - kazda 'jednotka' pouzivani prislizne appz bude stat kredit. Jednotkou je pak cas. Hodina/den/sekunda. Samotna busines logika faktura - zaplaceni - pusteni, je mimo rozsah tohodle, protoze to je spise otazka na ISM (resp. generovani faktur a podobne, to je na samostatny DOC). Pro tyto ucely to zjednodusme, ze se provede 'aktivace' na dany pocet dni (resp. do datumu) a pod.