Externi data ------------ Externi data (ED) je forma napojeni objektoveho sveta v CBS na jina data, ktera z principu nejsou a nebudou soucasti nasich vlasnich dat. Jedna ze zejmena o: - ciselniky - data z katastru - krabickova data Format externich dat -------------------- V zasade je mimo nasi jakoukoliv kontrolu a plne se prejima originalni 'format'. U nas se data neukladaji, nicmene muze vnikat lokalni kopie (tzv. seda) ktera umozni pristup k datum, kdyz zdroj bude offline. Jakozto zdroj se generalne rozumi: - nejaka forma API prez WEB - pristup k souborum v nejakem danem formatu - custom IP protokol (typicky krabicky, kde se bude jedna o komunikaci se serverem/databazi naraz) Jak referencovat externi data ----------------------------- Nezodpovezena fylozoficka otazka je, jak budeme data referencovat ve smyslu pricipu. Jedna moznost je, ze pro kazda 'data' ktera chceme vnikne objekt. A ostatni budou odkazovat na tento objekt. Nebo naopak, misto aby se vytvareli instance, se bude referencovat ED. Typicky priklad je ulice. Bud muzu mit nekde objekt 'ulice' ktery bude referencovat ID, nebo jakykoliv objekt bude moci refercovat ulici naprimo v ramci ED. V pripade katastru se logicky nejspise bude jednat o vytvareni instanci 1:1 v zasade, ale v jinych datech, jako napriklad data z krabicek, uz bych si tak jisty nebyl. Zatim vyjdeme z toho, ze ED by se mela referencovat JEDNOU a to pouze pri vzniku 'podrizeneho' objektu v ramci romankovo DB. Externi Data provider --------------------- EDP se rozumi general API pro pristup k jakykoliv datum. Umozuje implementaci vrstvy, ktera zpristupni samotna data pro zbytek systemu. Datove se na EDP muzeme koukat jako na hromadu dat, ktere tvori logicke celky (tabulky), jez mezi muzou mit nejake vazby. Vzdy uz dale resit nebudeme, budou vystupovat jako data, tkere lze pretahnout. Tj. EDP nemusi (a nebude) reflektrovat fyzickou strukturu pripojenych dat. Typicky: v katastru je ulozeny kraj jako vazba. Pokud nejaka cast objektovych dat bude chtit kraj, muze ho referencovat proste primo jako 'sloupec' v ulici aniz by musela nejak resit (resolvovat) vazbu na kraj. Paklize bude mit objektovy svet u existenci kraje, jakozto objektu, neni v tom samozrejmne problem. Z principu ale bude mozno vazby referencovat rovnou jako resovled (tak jako funguje data source). EDP z principu musi fungovat samopopisne, tj. exportuje kompletne sve struktury, nazvy, datove typy a pod. Aby nebyly vrstvy v CBS zavisle na typicky relacnim pohledu, stukturu dat poskytuje EDP 'runtime' s popisem jednotlivych casti jako pro strojove zpracovani (typ sloupce, alias, ...) tak i pro pouziti uzivatelem (prekladatelne nesmysly, jako nazev, pouziti a pod). Fyzicky se ED budou v ramci EDP resolvovat jako 2 specialni typy atributu: ED pointer --------- typ atributu, ktery ukaze do konkretniho EDP, na kontreni hromadu dat. Muze tez ukazat na konkretni sloupec nebo i radku. Pri vytvareni virtalu bude tento atribut ukazovat defacto na konkretni hromadu dat (v pripade katastru = tabulka) a pri vitvareni realenho objektu se bude ukazovat i na konkretni radku ED content ---------- atribut, ktery musi byt fyzicky priprazen pod vise uvedeny. jeho ukolem je pouze expandovat konkretni sloupec (nebo spojit vice sloupcu, pripadne aplikovat nejaky jednoduchy XLT) na hodnoty z prislusne casti dat (u katastru = radka tabulky). Pokud mi ED pointer ukazuje na tabulku 'ulice' pak muzu pouzit 'jmeno' a dalsi hodnoty. Veskere vazby, ktere jesou jednoznacne (u katastru napriklad prislusnost ke kraji) muzu rovnou referencovat. Tento atribut ve vysledku drzi kopii puvodnich dat. Tato kopie muze obsahovat data z vice casti. Pokud budu chtit, muzu vyslednou hodnotu utvorit jako "Topolova - Ustesky kraj". Z pohledu EDP se jedna o data ze 2 tabulek katastru, ale protoze hodnota klice se da resolvovat jednoznacne (neni vice hodnot), tak mi priskakuji moznosti referencovani z cele nadrazene struktury. Typ v objektovem svete NEMUSI korespondovat s typem na urovni ED. Zjednodusene lze referencovat tyto 2 atributy jako master/slave, kde master nema prakticky zadnou vyuzitelnou hodnotu a slavy jsou ty, ktere prebiraji hodnoty z ED. K tomu potrebuji prave svuj master. EDP musi umet vracet data na zaklade filtru z konkretni casti. Typicky vyber adresy. V tomto pripade CBS a cely system je je prostrednik, jediny, kdo tusi, co se vybira je aplikace, ktera z principu vi, ze chce adresu a tedy vi, ze ktereho EDP chce data (katastr) a ze chce ulice. EDP katastru radu dat slepi dokupy, protoze neni treba na vsechno nutne pouzivat vazbu, protoze deleni u nas nedava smysl a nepotrebujeme kompresovat data pomoci klicu :) Reference z techto app vrstvev bude na zaklade aliasu, ... Pri zakladni virtualu system muze sekundovat pri vytvareni nasledovne: 1. mastra: nabizet typ ED, posleze pak vyber z hromady dat (viz samopopisne nesmysly nahore) 2. slava: pak nabizet veskere atributy/klice/sloupce k dispozici, nebo zorazobat jejich seznam pri psani XLT. system by mel umoznit bud zvolit primo atribut nebo psani XLT Realtime hodnoty ---------------- EDP muze v ramci sveho popisu tatkez dane datove atributy zaradit do kategorie realtime. Typicky se toto bde pouzivat pro krabicky. Potom hodnota ostihoveho atributu neobsahuje realnou hodnotu, ale specialni referenci, kterou EDP preklada na hodnotu. System pri zobrazeni tohle provede zcela nezavisle na APP, APP pouze musi vedet, ze atribut se 'meni' v case a zajistit jeho update. Coz muze byt opet do znacne miry automaticke, ajax na updatovani muze byt generovan systemem na zaklade obsahu renderu stranky (system vi, co se zobrazilo). Takto bysme pak mohli pomerne snado zobrazovat i data z krabicek, kdy na krabicky by vnikl plnohodnotny EDP jako kazdy jiny. Data XLT -------- Tranformace dat z EDP do objektoveho sveta. Pro kazdy ED content atribut se spusti XLT, ktera muze prechroupat hodnoty, nebo je proste necha byt. Bude se jednat o obycejne TPL, kde se na konci plne provede trim hodnoty. Je tedy potreba dat pozor na vnitrni mezery, pokud se bude pouzivat 'if' nebo neco takoveho. EDP dopredu naucit, v danem schematu, prislusne variables. Vysledek templaty se pak stava hodnotou, ktera musi splnit pozadavky na typ. Nejjednodussi tranformace je tedy '{atribut}' ktery proste jen pretahne hodnotu as is. Lze pak referencovat ostatni sloupce v ramci IF podminek etc. A tedy vytvorit odvouzenou hodnotu zavislou na vice atributech dat. Nebo ji zkonvertovat a pod. Stinova data z ED ----------------- V kondifuraci EDP musi byt jasne receno, JAK se ma vytvaret podrizeni objekt. V podstate tedy odkaz na virtual a pripadne nejaka dalsi pravidla, na ktere narazime pri implementaci. Pokud so objektovy svet vyzada pristup k objektu, ma se na mysli to, ze system musi zajistit aby existoval objekt zadanych 'parametru'. Pookud jiz existuje - vytvaret se zamorejmne nebude. Tyto objekty si drzime z duvodu funcnosti jako takove. V zasade se jedna o kopii/extrakci dat, resp. pripadne aplikovanou tranformaci. Top level app proste zavola system 'potrebuju ulici XY'. A system vrati odkaz na objekt. Aby system tohle mohl jednoduse udelat, musi existovat vazba mezi aplikaci a ED. Ta bude na zaklade aliasu a samopopistnosti EDP. EDP zaroven exportuje 'typy' objektu, ktere dokaze stinove udrzovat. Metakod, bude tedy jen socuasti APP a v systemu by nemeli existovat zadne hardcoded vazby. APP uz z principu nemuze byt obecna, uz pracuje s konkretnima vecma a tedy pojem ulice uz je pro ni pomerne zasadni (z uzivatelskeho pohledu). Za idelani situace by neexistovali nepozuivane kopie a mohli se snadno mazat. Otazkou je, co na to apka, ktera aktualne potrebuje (nebo ne ?) existenci stinovych ulic pro smysluplnou praci. Pro aplikaci by to melo byt transparetni - prez jednu fci by mela mit pristup k prislusnemu stinovemu objektu a jiz dale neresit, ejsli vnikla kopie, nebo jiz objekt existoval. Aplikace musi rozlisit mezi vyberem z existujicich objektu a pridanim noveho. Resp. muze tyto 2 veci spojit do jednoho kroku. V obecne podobe ale system umoznuje hledani objektu a zaroven prohledavani na urovni EDP. APP muze tyto 2 vysledky spojit samozrejmne do jednoho dialog okna. Pak ale vyhleavani bude mene prehledne, zejmena co se tyka katastru a registru tvoru, ktery se volne potuluji po chodnicich venku. Je tedy na zvazenou, jak tohle uzivatelsky rozumne prizpusobit. Nedej bojze, any nekdo hledal Honzu Novaka :) ACL a ED -------- Mohou existovat ACL primo na ED. V tomto pripade EDP exportuje normalne ACL jako je jinde v systemu a je mozno je prirazovat. Ale v pripae katastru toto nedava smysl. Dalsi ACL existuji primo nad stinovymi objekty. Ze je nutno brat v uvahu na unik informaci postranima kanalama. Typicky, budeme-li stinovat ARES, tak samotna existence objektu pri hledani dava k dispozici moznost testovat, s kym existuji napr. podepsane smlouvy. Proto by ACL mela existovat minimalne v jedne zjednodusene podobe: stinovy objekt vidi ten, kdo si o jeho 'referenci' pozadal, nebo ma v ramci svych dat na nej vazbu. Tj. pokud nekdo jiny vytvoril objekt a on obsahuje 'Vomacka s.r.o.' tak ja, pokud mam prava na smlouvu, kde figuruje, ho taktez uvidim. To nam v zasade umonzuje neimplementovat aktualne zadna ACL, staci si, pri doplnovani vstupu, vise uvedenym zpusobem zjistit reference. Probem nastava pouze pri prvnotnim vytvoreni, kdy jeste neni reference nijak ulozena, ale objekt existuje. S vyse uvedenym zpusobem by ho uzivatel nevidel. Reseni jsou 2. Jedno na urovni aplikacni, kdy ID objektu samo o sobe umoznuje ho 'videt' (a tedy ulozit nekam ref). A po ulozeni reference uz videt bude. Side efekt je ten, ze pokud si zavedu 'Vomacka s.r.o.' na smlouvu, kterou nasledne smazu, pri dalsim hledani jiz 'vomacka s.r.o.' neuvidim a musi si ho zavest znova. Objekt sice nelze vymazat, ale pokud se budou brat v potazy reference v historii, tak ho uvidim navzdy. Ale pak uvidim navzdy vsechny, se kteryma neco kdy bylo. A pokud budeme brat jen zivet objekty, pak plati vise uvedene. Druhym zpusobem je, ze MNOU vytborene objekty budeme davat do nejakeho seznamu jen proto, aby byla reference.