Nice URL -------- Vitam vas u sveho dalsiho, tentokrate jubilejniho textoveho souboru. Neni ani tak unikatni tim, ze by byl nejaky v poradi... To ne. Je to jen dalsi z tisice a tisice pokusu o destrukci me, toho casu zasrane, klavesnice. Jubileujm mu nalezi okolnostmi za jakych vnika. Nebudu zacahzet do podrobnosti, jen se omezim na strohe konstatovani, ze neni nad to se poradne vysrat. Pro mene chapave, nebo priozralejsi, URL neni urologie, ale Unified Resource Locator. Tedy, mimo jine, i HTTP://server/adresa/cile/sex.avi Stav v ramci roku 2014 zacina kapitolou 2.0, 1.xx je vicemene stale platna :) Jen mezitim prisly webove sokety. 1.0 Co, proc, jak ----------------- Za davnych a davnych casu, kdzy vetsina z vas jeste parila prvni hry, my, skalni parani, jsme za sebou meli nejeden zlamany joystick. Postupem casu, nebylo co hrat a z nudy jsme stvorili boha. Potom hlemyzde, autonehodou slimaka. Pak nasledovala spousta dalsich hovadin, az po web. Za techto pradavnych casu, kdy pocitace byli duveryhodne stroje, si mezi sebou vymenovali obsahy svych dsku. Zadarmo, bez pravnickcyh tahanic. K tomu pouzivali URL. Prakticky vzato to byla cesta k dokumentu na danem pocitaci. V techto akademickych dobach to bylo plne dostacujici. Nicmene, protoze sem prisli penize, investori, businesmani, vsechno slo do hajzlu. Protokol HTTP, ktery vnikl, byl bezestavovy. To znamena, ze neexistuje neco jako "sezeni". Vse se smrskava na "chci" a "poslani" obsahu. Nic vic nic min. Idelani, jednoduche pro jednoduchy svet. Nicmene, HTTP se zacalo pouzivat i pro slozitejsi aplikace nez jen ziskavani obsahu, vicemene na urovni FTP (souborovy server). Postupem casu, se vyvynulo nekolik technologii, jak udrzovat vzajemnou soudrznost jednotlivych dotazu. Ta je nutna, protoze 'stejny' dotaz, muze u ruznych klientu vyvolat ruzny obsah. Napriklad "home page" si muze registrovany uzivatel nastavit sam a mit tam co chce, kde chce. Nebo jazyk a dalsi. Vse tedy vzniklo na zaklade nutnosti udrzeni "relace" (session). Diky tomu, ze je HTTP bezestatovy protokol, umoznuje chozeni 'vpred', 'vzad' a obecne 'skocit' kamkoliv. Ke vsemu se chova, jako kdyby to byl 'dokument' - statiky dokument, jeza posila vzdy stejny obsah. Fylozoficky. Postupem casu se vyvynula rada 'hlavicek' (data posilana mezi klientem a serverm, mimo kontrolu uzivatele) na kontrolu techto nekterych parametru. 1.1. Dynamicnost ---------------- Pod dynamicnosti se da predstavit dynamika v tom smyslu, ze web reaguje na uzivatele. Neni tedy staticky, jeho obsah se meni na zaklade rady ruznych okolnosti. Dynamika je myslena z hlediska zpracovani, ne obsahu. Dynamika se muze hodit jen pro udrzvoani session, tak pro vytvoreni fora, vyhledani a ovlivnovani obsahu. 1.1.1. Cookies -------------- Diky HTTP/1.1 muzeme ve hlavickach posilat tv. cookies. Cokies je vicemene serie 'hodnota=value', kterou server posle klientu. Klient potom toto cookie posila pri kazdem svem requestu. Kazda cookie pak muze jednoznacne identifikovat klienta, ukazovat do database a pod. Kazda cookie ma 'trvanlivost' a muze byt casove neomezena. Rozumne nastaveny kleint nicmene vsechno cookie maze pri uzavreni, neboli pouziva trvalivost 'end of session' (do ukonceni). Vyjimky pak tvori duveryhodne weby. To pak umoznuje automaticke priohlasovani, re-identifikaci klienta, sledovani identity a podobne. Cookie by mela byt platna jen v kontextu domeny/serveru a prohlizes by ji nemel posilat jinam. Cookies se hodne pouzivaji v reklamach, tzv. tracking cookeis, neboli cookeis ktere sleduji pohyb uzivatele po ruznych webech/domenach. Trikrat slava velkemu bratrovy. Cookie funguj nezavisle na skriptech (javascript, ...) Cookie jsou uzivateli neviditelne a neni jednoducha moznost, jak je nekomu predat (pro koncaka). Nutno podotknout, ze cookies se nemeni pri pozuivani funknci vpred/vzad. Pokud je cookie nastavena, zustava celou dobu v platnosti (tedy je to prinaseni 'stavu' do jinak bezestatoveho prostredi) 1.1.2. Formulare ---------------- HTTP umoznuje odesilat formulare. Formular je prakticky obdova cookie, ale jednorazova (val=hodnota). Nemusi nutne pochazet z vyzualniho formulare jako takoveho. Rada webu je vyuziva jako zakladni zpusob prochazeni po web. Formulare obvykle slouzi pro predani nejakych paraemtru serveru, kde uzivatel ma moznost neco volit (napriklad pri hledani je to 'co' hleda). Nevizualni formulare nemohou fungovat bez asistence skriptu. Formualre mohou vystupovat jako skryte (POST, neviditelne pro usera) nebo jako GET, tedy jako parametr. 1.1.3. Parametry ---------------- Protoze ani cookie, ani formulare se nehodi pro uchovavani stavu session, je hodne vyuzivana parametricka cast URL, tedy cat za ?. Jedna se opet o name=value seznam (oddeleni &). 1.2. Session ------------ Udrzovani session ma radu duvodu. Od identifikace uzivatele, az po zapamtovani si jeho preferenci, sledovani/logovani, umozneni fuknce dynamickeho webu jeako takoveho. Nejedna se tedy zdaleka jen o tracking uzivatele a jeho 'nejake id'. Do session patri jakykoliv VNITRNI stav 'terminalu' - tedy stavu kodu, ktery se stara o poslani obsahu klientovy. Prikladem budiz produktova stranka. Za dob statickeho webyu existovalo nekolik stranek: http://wwww.osukejmne.com/2030.html http://wwww.osukejmne.com/2030-detail.html http://wwww.osukejmne.com/2030-photos.html http://wwww.osukejmne.com/2040.html http://wwww.osukejmne.com/2040-detail.html http://wwww.osukejmne.com/2040-photos.html (6 ruznych fyzickych dokumentu) A tak dale. Kazda tato 'stranka' obsahovala staticky obsah, tedy vzdy dostupny (a pozuviala casto jine metody, treba SSI aby se nedubloval obsah). Cili, stranak vzdy vedela 'co' ma presne zobrazit. Postupem casu, ale vsechny tyto metody byli vytlaceny dynamicnosti, obvykle databazi, kde jsou stranky vicemene generovane centralne. Nakonec se treba rozpadnou do samostatnych templat, ale rozdil je ve fylozofii zpracovani. Nase produktova stranka by pak mohla vypadat: http://wwww.osukejmne.com/2030.html http://wwww.osukejmne.com/2030.html?co=detail http://wwww.osukejmne.com/2030.html?co=photos http://wwww.osukejmne.com/2040.html http://wwww.osukejmne.com/2040.html?co=detail http://wwww.osukejmne.com/2040.html?co=photos (2 ruzne dokumenty) No, pokud jsou produkety stejne, pak uz je pouze krucek ke globalizaci ve stylu: http://wwww.osukejmne.com/produkt.html?meno=2030&co=base http://wwww.osukejmne.com/produkt.html?meno=2030&co=detail http://wwww.osukejmne.com/produkt.html?meno=2030&co=photos http://wwww.osukejmne.com/produkt.html?meno=2040&co=base http://wwww.osukejmne.com/produkt.html?meno=2040&co=detail http://wwww.osukejmne.com/produkt.html?meno=2040&co=photos (1 fyzicky dokument) Veskere parametry jsou predane v ramci jedne URL. Na toto se da koukat porad jeste jako na staticky web. Staticky z hlediska serveru: obsah je staticky na zaklade URL. Kazda URL vyvola stejny obsah. Byt se to jevy jako dynamicnost, z hlediska nasich otreb se porad jeste pohybujeme ve statickych vodach. Prtokol HTTP nam nenabizi zadne jine moznosti jak udrzovat session pro uzivatele. 1.3. Strasti a pasti parametru a cookes --------------------------------------- Prohjlzies nemusi cookeis akceptovat. Vyhledavac uz vubec ne. Natoz ukladat. Cookie se tedy nehodi moc na predavani vnitrnich stavu. Ale problem je, ze je na nych vetsina webu zavysla. Nektere weby maji az desitky 'parametru'. Nabira zde otazka bezpecnosti a vyuzitelnosti. Typicky: www.web.com/search_result.html?pharse=co&pagelen=10 Typicky 'search'. Na webu vydime vyber stranky a delku - 10,20,50. No jo, co kdyz chci ale vsech 1000 vysledku ? Obvykle staci v URL prekopat nekolik parametrua hned cloveku leti vysledky jak chtel :) To pouzivam osobne casto. Ze 1000 radku zatizi SQL server ? Muj ne a kdyz to neosetri programator, ... Pomijim desitky dalsich moznych utoku. Cili, uzivatel je muze prepsat, vymazat. Poslat cast. Neposlat vubec. Co se stane, kdyz nekdo posle odkaz ala http://wwww.osukejmne.com/produkt.html ? Nebo kdyz vyhledavac odsekne vse za ? To bohudiky vyhledavac nedelaji, ani nesmi. Snazi se ale identifikvoat 'session id' a ty smazat. Obzykle itenfifikuji session, pokud je hodnota delsi. A prohlzec ? To same. A by to nebylo tak jednoduche, jeste zde mame firewally, ala zonealarm, kerio, ... ktere HTTP kod infikuji svym javaskriptem, prekopou odkazy a dokazou tyto vymozenosti 'vytipat'. URL muzeme tedy rozlozit z naseho hlediska na 2 casti: 1. dokument 2. parametry Co se tyce dokumentu (produkt.html) obvykle nebyva problem. S casti za ?, tedy parametry uz muze byt opruz. 1.4. Kde je vlastne problem --------------------------- Jadrem pudla je to, ze jiz neni konretni dokuemtn, ktery by si prohlizec pral zobrazit. Dnesni 'web' je naroubovan na HTTP protokol, kteyr mel zcela jine fylozoficke podminky vniku. Vnikl zivelym vyvojem, evoluci, nikoliv na zaklade pozadavku. Predstavme si produktovou stranku. Co potrebuje pro sve zobrazeni ? Radu veci... - prava uzivatele, co muze videt (treba cenu, interni informace, ...) - barvy/styl webu, jaky ma byt pouzit (zelena, cervena, ...) - produkt jako takovy - styl zobrazeni (fotky, detajjl, index, techicke parametry) - zvoleny jazyk a dalsi veci... Budeme to vse nazyvat 'varaibles' (abysme se vyhnuly kolizi s parametrickou casti URL). Nektere z nich se daji zjistit z dabaze produktu, jine musi system odnekud vycucat. Tyto parametry se daji rozdelit do nekolika typu: session (terminal) variably, ktere plati po celou dobu session a jsou nemenne (ci se meni malo) a jsou nezavisle na kontextu. Typicky nejaka identifikace uzivatele, zvoleny jazyk, velikost fontu a podobne. Nezavislost na kontextu znamena to, ze dana variabla ma logickou platnost kdekoliv na webu, bez ohledu na cas, prechozi stranku a podobne page variabla, ktera ovlivnuje konkretni stranku, velice casto meni svoji hodnotu, nema vyznam jinde, a narozdil od per session, se jeji hodnota meni hlavne pri odkazovani. Typicky jsou zde vbariables ala prdukt id, sort sloupec, stranka ve vysledcich a podobne dekoracni je podsupina 'page'. Jsou to variably, ktere nejsou ptoreba pro zakladni zobrazovani. Pokud bude schazet, tak se obsah poskytne ve spravne formne. Typicky jsem mzue patrit sort sloupec, zvyrazneni nejake casti a tak dale Problemy tedy v zasade jsou: 1.4.1. Predani variables ------------------------ Jak si predavat mezi klientem a serverem data ? Kliet klika na odkaz. V odkazu a pripadne cookies musi byt zahrnuty veskere potrebne variables pro zobrazeni konkretni stranky. Cim slozitejsi stranky jsou a cim vice zobrazuji dat, moznosti a hovadin, tim vice parametru mohou potrebovat pro sve korektni zobrazeni. Zde je nutnost podotknout, ze pomoci 'cookies' jde ptredavat vicemene pouze 'session' varaibles. A protoze vetsina session muze byt ulozena na strane serveru, tak cookies je v zasade pouzitelne pouze pro ukladani identifikace session (a pak nasledne na serveru session resolvovat a priradit userid a dane per-session varaible). To zarovnen usetri prenosovou kamacitu a zvysi rychlost, protoze se nemusi pri kazdem requestu posilat mezi serverem a klientem cookies dokola a dokola. Variablu muze byt relativne velek mnozstvi... 1.4.2. Dynamicky obsah ---------------------- Co platilo pes 5ti minutama je jiz minulost. Odkaz na '5tou stranku' ve vysledich se mzue menit kazdym, okamzikem. To same plati pro ruze news a podobne. Rict nekomu podivej se na stranky 'http://www.orcave.com' a v pravo nahore klikni na ... muze platit den, dna, hodinu (v nasem pripade i rok :) Pointa zustava, ze data jiz nejsou staticka a samotne URL jiz nedostatecne identifikuji, na co se vlastne clovek chtel podivat. Casto se pouziva v tomto ohledu pojem 'pernametni link' coz je odkaz na aktualni stranku utvoreny tak, aby obsah, vytvoreny kdykoliv v budoucnu, odpovidal vicemene i aktualnimu stavu 1.4.3. Caches ------------- Veskere linky, nekde ulozene, at ji zu nas, nebo na jinych webech jsou v podstate cache. Reflektuji nas web v nejakem konkretnim okamziku. Ale i URL sama o sobe zastarava. Do techto caches se muzou ulozit nazvy produktu, ruzne varaibles, ... a webmaster se pak nemusi stacit divit, kam vsude se lidi dostanou i po nekolika letech. S timto pojmem se casto pouziva v souvilosti 'redirect'. Tj. sada pravidel, kdy (obvykle) po zmene webu je nutno zachovat i funkcnost starych URL. Krasny prikald je MS, kde se da kliknotu na dokumentaci z roku 95. A svete div se, nekdy se zadari a prez 2-3 redirekty to ukaze spravny obsah. Nicmene, tato rezie stoji ohromne usili 1.4.4. Obsah jako takovy ------------------------ Co vidi oci me nemusi videt oci tve. Kazdy user muze videt rozdilny obsah na stejnem URL. Napriklad vlivem ACL, nebo proste protoze ma nastaven "ten spravny jazyk", nebo si jeho prohlizec vyhednal jiny typ obsahu (napriklad pro jine zarizei, ala PDA). 1.5. CBS ---------- CBS pouziva vsude aktualne 'parametry'. Aby se vyhnulo bezbepnostim rizikum, pouziva 'ssid'. Neni to nic jineho, nez 'val=hodnota&val2=hodnota2' jak je v klasickych parametech, je to pouze encodovane aby to neslo rucne menit (a kryptovane). CBS vychazi z toho, ze ani jeden z vyse uvedenych problemu nebyl rozumne doresen, tak pro jistotu URL nepozuiva vubec. do WWW se planovalo nasazeni 'nice URL', ale nedoslo k nemu. URL je vstup, se kterym si server mzue delat co chce. Exituje tuna moznosti, jak s URL nalozit. Napriklad pro apache to je mod_rewrite (ktery mimochodem CBS pouziva), prez tuny dalsich moznosti az po 'vlastni' zpracovani (to aktualen CBS pouziva, ve spolurpaci s mod_rewrite). Zakladnim pruserem je, jak udelat URL... Stranka se sklada z tempalt, nebo XLT. Je to vicemene jedno. Kdo nejakym zpusobem musi nacist kus databaze, nejak ho zobazit a poslat klientovy. Pri vytvareni linku potom musi vhodne pripravit varaibales pro 'dalsi' kliknuti. To vse ma CBS aktualne sestavene do jednoho 'velkeho ssid'. Rada variablu lze presunout na server side a identifikaci klienta zajistit pomoci cookie... To ale neresi problem... Problem je, JAK sestavit URL ? To je jadro pudla. Je to otazka SEO, organizace dat, je to spise otazka fylozoficka nez technicka. 1.5.1. Detajly -------------- Aktualne je CBS zalzoene na templatach, nebo XLT, ktere sou na templaty linkovane. Proto se budu zminovat jiz jen o templatach. Templay tvori strom, ktery mzue byt pomerne dost kosaty. Obsahuje mnoho ruznych variables. Rada varaibles je 'systemova' - napriklad, jaka barva, zarovnani, styl a podobne. Ty se se ridi vicemen z databaze a nemusi se predavat. Tyto variably se buodu muset pripadne identifikovat a klasifikvoat jako 'do not pass' v ramci CBS. CBS totiz zajistuje, ze dokud je dana templata vyuzivana, potom veskere jeji varaible jsou obnovene pri dalsim requestu (teyd dela z HTTP stavovy protokol). Tpy varaibles jsou v BCS definovatelen v properties. Pri vyvoji webu mela byt venovana vetsi pozornost tomu, jakym zpusobem se web vyvyji a vyuziva tyto veci. Mam pocit, ze ted vvetsian variablu bude brana jako 'stavova' ikdyz to potreba nebude. Priklad: www.orcave.com/nejakastranka.html?produkt=2030&barva=zelene Takto driv axlovy fungoval web (barva=zelena bylo interne delane CBS). Potom ale zmenil system a barvu urcuje 'hlavni' templata na strance. Proto by stacilo www.orcave.com/nejakastranka.html?produkt=2030 protoze 'barva=zelene' se nacte z produktu. Jsou ale stranku, ktere barvu neurci a potom se tato variabla musi nadale chovat jako staticka. 1.5.2. Lidi verzus stroj ------------------------ V CBS vetsian veci funguje na zaklade cisel. Realne parametry vyapdaji v CBS takto: 1466=13&8751=45&9844=4456 Mam pocit, ze toto neni moc vhodne na jakekoliv rucni zachazeni. Budou se tedy msuet transformovat jak jmena, tak hodnoty 'variabel' do casti URL. Nemely by ale byt z DB jak je, protoze vetsina veci podleha prekladu a jeste si zeslozitit zivot prekaldatelnou URL, nevim nevim... jsou lepsi veci jak travit cas, treba chlastat nebo sukat, nez delat prekladaatelhou URL. 1.6. Reseni ----------- Nastinil jsem systemove problemy a duvody, proc CBS nepozuiva URL a proc bych ji neral pozuival jako stejejni. Nicmene, protoze SEO, linky a dalsi veci by bylo dobre mit nice URL. Abychom meli ncie URL, je potreba udelat nekolik kroku 1.6.1. Co tam bude ------------------ Musi se definvoat CO budeme v URL chtit ukazovat, jakou formou. Osobne bych se drzel nasledujicich pravidel: - nepozuivat cilovy dokuent, jen cestu (ala http://www.orcave.com/produkty/2030) - cesta k produktu by mela byt rozumen dlouha a obsahovat i jeho zakladni rysy - ala 10ghz a dalsi (SEO) - muzeme pouzivat i domenyu treti urovne, napriklad http://10ghz.orcave.com/...) - neprekladat URL, zasadne EN - URL muze mit nekolik nezavysluich casti, napriklad volba jazyka muze byt http://www.orcave.com/produkty/2030 - to co vyjedna prohklziec http://www.orcave.com/cz/produkty/2030 - explicitne CZ - URL musi byt 'zpracovatelna' strojove, tedy pravidla pro tvoreni URL musi byt obousmerna varibales -> URL URL -> variables - vhodne pouzivat - / kombinovat je ala http://www.oracve.com/produkty/10ghz-18ghz-20ghz/101x-1013 Technicky vzato, bude URL: http://prefix.orcave.com/NICE/URL/?parametry&chvost prefix - zakladni SEO slova, pokud budou NICE/URL - poskaldana URL parametry - nejake rozumen parametry stranky, jazyk a dalsi (pokud nebudou soucasti URL) chvost - to co ma CBS ted, jen v jine kratsi podobne - nemelo by to byt potreba pro funkcnost webu a pokud chvost nebude platny, CBS usera presmeruje na sdresu 'bez chvostu' 1.6.2. URL ---------- Jak jiz bylo naznaceno, URL musi tvorit 'templata'. Jenom TPL kod vi, 'co vlastne je'. Jeden TPL kod muze byt mnoho URL. Jeden TPL kod muze byt index produktu, detajl, ... cokoliv. Jeden TPL kod muze byt dokonce cele forum. Pokud CBS dostane nice URL, musi byt shcopno ho prekonvertovat na 'varaibles' a posleze volat kod. Samotny kod by mel byt od URL *UPLNE* odstinen a kromne generovani 'ja jsem x/y/z' by nemel do tohoto procesu jinak zasahovat. 2.0. Realne provedeni leta pane 2014 ------------------------------------ Po letech planovani, pilovani, testovani a branstormingu jsme se konecne odhodlali drzet krok s pochybnou dobou a realizovat plan na zachanu sveta. Toto budiz poselsvi pro budouci generace. Kupodivu navrh z roku 2007 zustal relativne nezmenen. NU je plne transparetni vuci 'webu' a tvoreni linku, preklad z template itemu na URL a opacne probiha zcela automaticky a neni treba NU jakkoliv resit, krom samotneho definovani. NU (Nice URL) funguje ve 2 oddelenych fazich. Prvni fazi je prevod WWW LINK -> NICE URL a druhy je potom prevod URL -> WWW LINK NU chape URI jako cast, poplatna v ramci virtualni webu, to jest: www.orcave.com/dohled/adresa/sem pro virtualni web 'www.orcave.com/dohled' je URI rovno '/adresa/sem', to jest, NU je mozno provozovat bezproblemove i v ramci 1 domeny. Rozhodnuti o virtualnim webu (hostu) je provadeno pred analyzou NU. Pokud bu 'orcave.com' zaroven definoval NU cast 'dohled' tak prevazi definice virtulaniho hostu a tato cast na orcave.com, smerovana z '/dohled' pristupna nebude. NU podporuje 3 typy 'nice URL': URI cast (dynamicka) klasicke URI je v zasade cesta ke zdroji, takze: www.orcave.com/ble/zoo/kuk?neco=necojineho definuje URI=/ble/zoo/kuk. Tato cast je plne v kompetenci NU ktere obousmerne preklada linky. Link se sklada plne 'realtime' bez jeho dopredne znalosti staticka URI cast cast URI, kde je pevne dana jeji pozice a vyznam, aktualne neimplementovana, protoze neni potreba. principielne sem bude patrit zejmena: jazyk www.orcave.com/cz/produkty/... www.orcave.com/en/products/... www.orcave.com/produkty/... (vychozi) aby system mohl v ramci NU casti ktera bprez lng string definguje 'produkty/products' rozhodnout, jaka mutace se pouzije, NU predpoklada ISO kod jazyka jako prvni cast URI. session + TPL variables pokud nebudou dostupne cookies, muze system ukladat session ve formatu www.orcave.com/aBgzZ1/zbytek/URI nebo www.orcave.com/URI/?ssid=aBgzZ1 Tato cast je fixni, system ji rozpozna autoamticky a zpracovava ji pred samotnym URI. Delka je fixni, cca 8 znaku je dostatecne pro bezpecny provoz. Pokud nekdo nakopiruje link se session ID a system zjisti, ze je z jine IP adresy, nebo je session jiz nevalidni, protze zalozi jinou a presmeruje se autoamticky na "www.orcave.com/NeCoJiNeho/zbytek/URI". Toto chovani muze byt ovlivneno uzivatelem, kdy popsane implicitni chovani bude jen pro usera 'www' a podobne, pro realna konta by se mela zobrazovt chybova stranka. Je mozno volit mezi ukladanim session mezi URI a cookies. Cookies jsou nicmene predmetem zajmu EU a picovin. Tyto 3 moznosi jsou volitelne. Zatim je nemam implementovane, az po dokonceni samotneho NU dojde k presunu/odstraneni SSID a URL zustane 'cista'. Aktualne je vzdy SSID pritomto v parametricke casti, ale jiz se v nem NIC nepredava (sam o sobe) V ramci TPL itemu se v SSID predavaji i hodnoty itemu, odkazovanych v linku. Pokud templata bude mit vsechny tyto itemy, ktere nejsou 'no auto pass' definovany jako NU nebo jim hodnotu predavat v linku nebude, lze SSID odstranit zcela. Tato cast SSID nelze predavat jako cookies. Z toho plyne, ze SSID muze byt promene co se tyce delky a pak neni vhodne pouzivat prefixovanou formu u URI. Ta je vhodna jen pokud TPL budou plne vyuzivat NU. V systemu lze plne zakazat predavani parametru pro celeho hosta. Nicmene, predavani prametru v ramci SSID je bezpecne - v ramci NU nikoliv ! SSID je kryptovane a lze si bezpecne mezi templatama predavat i citlive informace. Zejmena v aplikacich bych se tedy SSID primarne nebranil, specialne pro AJAX requesty a podobne 'nevizualni' casti. parametrickou cast cast za ? (neco=necojineho) Obecne existuji URI casti ve 2 typech: pritomno/nepritomno/seznam value+hodnota Klasicke pritomno nepritomno je jasne, bud data polozka v URI je nebo neni. Pokud se jedna o nataveni nejake hodnoty, v parametricke casi ma std URL tvar - tedy name=hodnota. Jeli pouzit seznam jakozto 'value' potom se pouziva ODDELOVAC SEZNAMU, platny vzdy pro cely virtualni host. Pouzije-li se value+hodnota v casti URI potom se generuej NAZEV[ODELOVAC HODNOTY]VALUE. Oddelovac hodnotu je taktez nastaveni virtualniho webu. Napriklad, 'sort' muze byt generovat: www.neco.com/bleble?sort=sloupec www.neco.com/bleble?sort=sloupec,sloupec2 www.neco.com/bleble/sort--sloupec+sloupec2 (-- a + jsou oddelovace) www.neco.com/bleble/sloupec1/sloupec2 www.neco.com/bleble/sloupec1+sloupec2 Fakt, zda-li je pouzit prvni nebo druhy format urcuje NU item. Pri zpetnem prekladu system 'nevi' v jakem poradi jsou predavany NU itemy. Pokud ma URI fungovat i z hlediska uzivatele a skriptu (kere ji magi generovat), tak na proadi nesmi zaviset. Proto na poradi NEZAVISI. Je zde jedna vyjimka a to jsou odkazy do dat. System zpracovava URI zleva - cast po casti. Na zacatku jsou ve kre vsechny stranky. Vezme se prvni item a zjisti se, ktera stranka by mohla 'pasovat'. Tim se omezi seznam. A jde se dale. Pokud seznam zustane prazdny, je generovana chyba - po otestovani a dopilovani to bude presnerovani na danoustranku, kde muze nejaka patricna templata zabrecet, jak je ji to lito a ze nesplnila svuj ucel. Zde je jeden logicky dusledek - pokud system nenajde 'text' z URI z textu v ramci itemu/skriptu a na strankach v uzsim vyberu EXISTUJE nejaky data source v ramci URI - system ZKUSI vybrat, dle skriptu, patricne ID dat. Proto vzdy posouvejte datovou cast co nejvice 'doprava'. Zaroven to znamena, ze pokud nejaka templata ma svuj 'item' na patricny text, tak NEDOJDE k prozkoumavani DAT ! Takze pozor na kolizi URI v ramci dat a textu - napriklad jmeno produktu a podobne. Mejme templatu 'A' ktera linkuje do nejake tabulky produktu a ma nastaveny data set na produkt. Potom by fungoval link www.neco.com/1s10 (jakozto produkt). System narazi na '1s10' a zjisti, ze nema zadny 'text' handler, ale ze tempalta 'A' disponuje data sourcem, tak zkusi select - a hle, 1s10 se najde. Takze se tato templata spusti. Pokud by nekdo pridal templat u 'B', ktera by definovala staticky NU item '1s10' jako specialni stranku o 1S10 tak ten sami link by skoncil na teto template, protoze system by nasel text handler a jiz by se nepokousel o data. Pokud by templata A mela dalsi NU item, rekneme 'detajly' a templata 'B' potom 'obrazky', tedy meli by existovat www.neco.com/1s10/detajly (-> A) www.neco.com/1s10/obrazky (-> B) tak druhy odkaz skonci chybou, protoze templata 'A' vyradi z heldani 'data' a tim padem i templatu 'B' a 'obrazky' templata A nema, takze vypadne -> chyba. Dtto plati pro stejne templaty na vice strankach. Je potreba NU itemy ovlivnit prez value, jinak system, pokud mu vujdou 2 cilove stranky, nebude schopen rozhodnout kterou ma zobrazit -> chyba. Obecne tedy umistovat 'data' URI doprava, aby existovalo co nejmene strankek (templat) ktere system pak bude zkouset. Na tyto sloupce *MUSI* existovat indexy !!!!!!!!!!!!!! Aktualne je musim (na datech) udela ja nebo roman. Takze tyto sloupce hlasit, nez do DTD pridame custom indexy. Z toho vypliva, ze v zasade jemozno linky v CBS pouzivat ve formne 'a href' a psat je rucne. Toto vrele nedoporucuju, protoze struktura pak bude hardcoded, kdezto klasicky link umozni zachovat dynamicnost - stranky budou fungovat i pri zmene struktury - jen se zmeni patricne NU itemy. Z vykonostnho hlediska je zde problem v tom, ze kazdy link se musi zpracovat a znamena pristup do DB, takze ty casti URI, ktere jsou dynamicke (z DB) davat co nejvice 'napravo' a mit co nejvice vlevo, aby se prohledavalo co nejmene potencionalnich cilu. Taktez nas ceka optimalizace na uropvni DB, kdy bude dobre tyto dotazy cachovat, ale protoze CBS pristupuje k datum systemove, neni s tim jedinny problem, vykon server se pak rapidne zvisi. 2.1. Nastaveni NU ----------------- Nastaveni NU soucasti kazdeho itemu. Kazda templata muze exportovat 0 a vice NU itemu. NU item je cast URL, obvykle tvorena znaky mezu / a nasledujicim /. Aktualni neni mozne, aby 1 NU item definocal vice URL casti. Pokud je tedy, ve ire v lepsi komfort uzivatele, nutno udelat URL "ja/nevim/co" pak to musi byt 3 nezavisle NU itemy. Kazdy tempalte item ma tedy svou NU roly. Nektere role maji vyznam jen pro konrketni datove typy, ale NU system je principielne neomezuje, krom pripadu, kdy je zavislost zjevna (data_ref napriklad). NU system zaroven z typu sam nic nedovozuje, takze pokud mame DATA SOURCE nebo DATA_SET a podobne, je nutno nastavit korektni NU roly. Obecne neni dobry napad pouzivat LNG stringy v ramci NU, protoze tato podpora neni zatim udelana. Principielne lze dodelat dle potreb a jazyk nastavoat jako cast URL nebo na zaklade vyjednani obsahu browserem. NU role mohou byt: none item nema zadnou rolu v ramci NU a je NU zcela ignorovan static item exporuje 'text' to NU - jako text sde bere jeho HODNOTA data_set u itemu typu data_set je mozno do NU exportovat jeden a vice radku z data_source select select z nekolika hodnot list seznam z hodnot Kazdy item v ramci NU ma tyto nastaveni: kind NU role Priority system sklada link z jednotlivych casti, ktere pak radi dle priorit. stejne priority mohou byt v URI serazeny NAHODNE ! Pri zpetnem rozkladu URI na LINK na poradi nezalezi, pokud jiz byla nalezena cilova stranka/templata. dokud ma system vice moznosti pri vyhledavani, tak na poradi zalezi Destination cil NU casti: URI vs params Script detajlni popis NU vlassnosti, ktery je zavisli na kazde roli (bude popsano dale), ktery ma obecnou syntax: va1,val2[,...valN]. System vyplnuje tuto kolonku AUTOMATICKY (je read only) pokud NU role odpovida item typu, z jehoz vlastnosti se vygeneruji automaticky. Pokud z nejakeho duvodu nechcete automaticky doplnit, potom staci dat item jako text/int a system do toho nebude kecat.