49 komentářů k článku JavaScriptové MVC frameworky (reakce na článek Ondřeje Žáry):

  1. Tom

    Reakce na reakci na článek
    Pěkný článek, ale hodně subjektivní. Připadá mi, jako kdyby autor někdy v minulosti šlápl vedle, a teď se to za každou cenu snaží nějak obhájit. Článek Ondřeje Žáry je mnohem přínosnější.

    1. Martin Hassman

      Re: Reakce na reakci na článek
      Vyčítat subjektivním článkům, že jsou subjektivní, je asi jako vyčítat seriálům, že mají více dílů. Není to bug, ale feature 8-) Cílem autorů nebylo napsat lepší článek než ten druhý autor, ale popsat svůj osobní pohled. Pokud někdo další přidá svůj, rádi ho vydáme.

  2. Lukas

    Este a google closure
    Uz je to fakt az unavujici me prijde porad a neustale od Daniela cist a poslouchat propagaci reseni postavenym na google closure a Este.js, podle me je dobre zkouset a vymyslet neco noveho, nebot kdyby kazdy pouzival jen to co je napsane a nejak vyresene tak by se nikdo, nikam neposouval. Rozhodne toto reseni ma sve vyhody ale opravdu je potreba toto neustale omilat dokola ?

    1. Petr

      Re: Este a google closure
      Naprosto souhlasim. Ze stejneho duvodu jsem prestal chodit na jakekoli akce, kde se tento pan trpici God-modem vyskytuje. Ondrej Zara si holt dovolil kecat do tematu, o kterem smi mluvit a publikovat jen Ten, jehoz jmeno se nevyslovuje. Ano, vsechny MVC frameworky jsou na ho*no, jen Este (mimochodem, tento vyraz je v tomto kratkem clanku pouzit 22x) je dokonaly a presne z toho duvodu ma na Githubu score 25×2 a od Ase na zapad o nem nikdo nikdy neslysel… To myslim mluvi za vse :-)
      Autorovi bych doporucil alespon 3x precist vynikajici clanek http://www.growjob.com/clanky-personal/mentalni-mor-vlastni-neobjektivita/

      1. Daniel Steigerwald

        Re: Este a google closure
        Nečtete dobře. Nepsal jsem, že jsou všechny na hovno, jen jsem psal, že nemají dobrý routing, a odkázal jsem na článek, který SPA v detailu vysvětluje. Některé vlastnosti jsou implementované v Este. V ostatních frameworcích ne. To je celé.

      2. keff

        Re: Este a google closure
        Vim ze riskuju flame, ale Dan ma v mnohem pravdu – javascriptovy framework ala Nette, tzn. ve kterem defaultni zpusob delani veci je ten dobry pro vyvojare i uzivatele, a ktery abstrahuje (dobre!) cast slozitosti platformy tak, ze o nich zacatecnik vubec nevi a pritom je udela dobre, ten tu jeste porad neni. Takze je imo dobre se bavit o tom, co tem dnesnim chybi.

        Za sebe vidim v Nette vs. Este rozdil (ve frameworcich i autorech) – ten Daviduv je i pro zacatecniky, Danuv ma latku pro uzivatele nastavenou vys.

    1. Daniel Steigerwald

      Re: A příklad?
      Na TodoMVC Este zatím není. Plánuji ho tam dodat, ale čekám na nové TodoMVC pro jazyky, které se kompilují do JS. Addy už na tom maká.

  3. Filip.Jirsak

    bezpečnost?
    Bezpečnost je snad naopak výhoda manipulace s DOMem, ne? HTML/script injection (a jeho podmnožina XSS) je přece postaveno na tom, že uživatel místo „obyčejného“ textu vloží text ve speciálním formátu, který je parserem interpretován jinak než obyčejný text. V případě manipulace s DOMem tam žádní parser není, takže není co obelstít. V případě šablon stačí udělat něco jako „“+vstup+““, a máme injection jak z čítanky.

    1. Daniel Steigerwald

      Re: bezpečnost?
      To ne. Šablony defaultně vše escapují, prosté ani jiné +vstup+ injection tak nefunguje. Musíte explicitně šabloně říct, „tohle neescapuj“. Manipulace s DOMem vypadá snadněji, stačí nepoužít innerHTML.. jenže XSS je zranitelné i pro attributy, a na to každý už nemyslí.

      1. Filip.Jirsak

        Re: bezpečnost?
        Šablony nemůžou defaultně vše escapovat, to by pak byly k ničemu. Kdybych ze šablony dostal na výstupu defaultně <p></p>, k čemu by mi šablona byla? Do atributů, které by byly zranitelné, se uživatelský vstup vkládá asi jen málokdy.

          1. Filip.Jirsak

            Re: bezpečnost?
            Pokud se proměnné vkládají tím správným způsobem. Pokud se vkládají způsobem uvedeným výše (čemuž nic nezabrání), tak escapované nejsou. Ano, šablony jsou určené k tomu, aby se mnou uvedený způsob nepoužíval – ale pořád to jen usnadňuje řešení problému, který při manipulaci s DOM prakticky neexistuje (ano, pokud budu uživatelský vstup vkládat rovnou do img/@src nebo do */@style, je to bezpečnostní díra – ale ta tam bude i při použití šablon, protože to byl musel mít šablonovací systém křišťálovu kouli, aby tohle „oescapoval“).

            1. David Grudl

              Re: bezpečnost?
              Řetězce v atributu src je escapují stejně, jako třeba v atributu title. Tj. dvojice znaků uvozovky a & se převedou na entity.

            2. Martin Hassman

              Re: bezpečnost?
              Systém tu křišťálovou kouli přeci má – ví, kam to chceme vkládat. Nevím teď jaké všechny šablonovací systémy, ale řada jich tohle opravdu rozpoznává a řeší a osobně tohle vidím jako cestu budoucnosti oproti neohrané práci s DOM.

              1. Filip.Jirsak

                Re: bezpečnost?
                Když do DOM atributu src tagu img vložím uživatelský vstup „http://mujserver.hacker.cz/sleduju-te.php“, je to bezpečnostní problém. Když tenhle vstup vložím do šablony, escapují se uvozovky a ampersand, čili se nezmění nic, a na výstupu budu mít to samé, jako s DOM, tedy stejný bezpečnostní problém. Šablonovací systém křišťálovou kouli nemá – neví, že obrázky z „http://galerie.ja.cz“ jsou OK, ale z jiných domén ne.

                V tomto jsou si tedy oba přístupy rovny. Další případ jsou znaky se zvláštním významem – o těch asi píšete vy dva. Při práci s DOMem takové znaky neexistují, takže není co řešit, šablonovací systém je při správném použití možná správně escapuje. Takže tu pořád ještě zbývá prostor pro špatné použití šablonovacího systému a pro nedostatky v escapování*) – nebo-li DOM není z pohledu bezpečnosti nikdy horší, v některých případech může být lepší, a tedy v porovnání DOM a šablonovacích systémů je větší bezpečnost výhodou DOMu.

                *) Udělat správné escapování pro obecné HTML interpretované v prohlížečích je velmi složité až nemožné. Prohlížeče totiž interpretují i chybný HTML kód, a každý prohlížeč to dělá jinak. Parser by tudíž musel interpretovat kód stejně, jako všechny prohlížeče – takže by pak třeba byl ve stavu „na tomto místě je Trident uvnitř komentáře, Gecko je v textu elementu a WebKit je uvnitř atributu, následující znak musím escapovat tak, aby se všude interpretoval správně“. Podle mne je nemožné takový interpret šablon napsat.

                1. Martin Hassman

                  Re: bezpečnost?
                  Bezpečnost v případě DOMu nebude horší, to je celkem jasné. Ta volba šablon neprobíhá z důvody bezpečnosti, ale z jiných důvodů (lepší údržba kódu apod.).

                  S chybným HTML kódem nebude problém, když si na něj dáme pozor, což jde.

                  Ale na takhle obecné úrovni se prostě špatně argumentuje „já si myslím, že šablony jsou špatné“ vs. „dělají se bez problému“. Vezměte si třeba šablony, které používá Nette (zatím v PHP, ale on je David časem do toho JavaSciprtu dostane) a ukažte na ni, co zde tvrdíte. Předveďte, že špatně escapují. Uvidíme, zda se vám to podaří. Tím se naše diskuse může posunout dál. Zdá se mi totiž, že jste pořádné šablony nezkoušel, a proto je podceňujete.

                  1. Filip.Jirsak

                    Re: bezpečnost?
                    „Bezpečnost v případě DOMu nebude horší, to je celkem jasné.“

                    Mně to také připadá jasné, ale článek vyznívá přesně opačně – uvádí (větší) bezpečnost jako výhodu šablon proti DOMu.

                    Nemyslím si, že šablona může escapovat bez toho, aniž by věděla, zda se momentálně nachází např. v HTML kódu nebo v JavaScriptu. Ostatně v dokumentaci Nette je napsáno, že to právě tak dělá. Jenže někdy to nelze obecně rozhodnout, záleží na vykreslovacím jádru. Třeba tenhle kód:

                    alert(1);

                    Uzavírací tag komentáře je napsán chybně, je tam mezi dvojpomlčkou a většítkem mezera. Podle HTML standardu je to chybně, dvě pomlčky se v komentáři vyskytnou nesmějí, mohou pouze v kombinaci s většítkem uzavřít komentář. Jenže prohlížeče se s tím nějak popasují – a pokaždé jinak. WebKit a Trident (v plusmínus aktuálních verzích) komentář neukončí, takže celý zbytek kódu (včetně „skriptu“) je součástí komentáře – escapovat by se tedy měly jen dvojpomlčky. Gecko komentář ukončí, po něm tedy následuje skript, který se normálně provede – a escapovat by se mělo jako v JavaScriptu. Teď nastává ta správná chvíle pro křišťálovou kouli, která by měla rozhodnout, která varianta je správně.

                    Když z toho teď udělám šablonu, bude z toho v Gecku ukázkové XSS:
                    Jméno: ${loginName}

                    Najít tenhle rozdíl v parsování mi trvalo asi minutu, kolik jich asi je celkem?

                    1. Filip.Jirsak

                      Re: bezpečnost?
                      Hm, bez náhledu komentáře to asi bude složité…
                      První kód:
                      <!--
                      - - >
                      <script>
                      alert(1);
                      </script>

                      Druhý kód:
                      <!-- - - > Jméno: ${loginName}

                    2. Daniel Steigerwald

                      Re: bezpečnost?
                      Nemáte pravdu a navíc jste hrozně nestručný, což je ještě mnohem horší. Z vašich komentářů je zřejmé, že jste problematiku studoval, a snažíte se zakaždou cenu popřít mé trvzení. Co se týká mallformed HTML v šabloně, o kterém pochybuji, že by programátor napsal, protože by mu okamžitě přestal fungovat syntaxy highlight, tak vás můžu ubezpečit, že ani tak se takové HTML do šablony v Closure nedostane. Soy šablony se kompilují na serveru, a pokud je v šabloně špatné HTML, compier zařve. Vidíte. Kdybyste více studoval co jsem tu odkazoval, mohl jste si ušetřit tolik dlouhých komentářů, a nám jejich čtení.

                    3. Filip.Jirsak

                      Re: bezpečnost?
                      Uváděl jsem příklad, ve kterém se dva parsery neshodnou na tom, co je špatné HTML. Když k tomu přidáte třetí parser (Soy šablony), situace s nekompatibilitou se určitě nezlepší.

                      Nestručný jsem, protože mi připadá, že se nechápeme, tak se snažím to vysvětlit podrobněji. Jinak si nedovedu vysvětlit, že by někdo myslel vážně tvrzení, že šablony jsou z pohledu XSS bezpečnější, než manipulace s DOM. Je to stejné, jako by někdo tvrdil, že escapování v SQL dotazech je bezpečnější, než binding proměnných. V případě SQL už se na to přišlo, že escapování problém neřeší, ale jenom maskuje – a zpravidla ne moc úspěšně. Je potřeba na to u JavaScriptu přicházet znova?

                    4. Martin Hassman

                      Re: bezpečnost?
                      Jestli se ty kódy nyní zobrazují správně, tak tam žádný problém nevidím. loginName se normálně zaescapuje, pokud to programátor cíleně nezakáže. Zkuste nějaký příklad, který si opravdu vyzkoušíte. Myslím OPRAVDU vyzkoušíte. Máme tu v ČR stovky programátorů, kteří těmto šablonám věří (patří k nim), pokud ukážete opak, natrhneme nám všem tričko a dokážete, že David Grudl je lhář, když je obhajuje. Nevěřím, že se vám to povede. Ale zkuste to. Ne zde v komentáři, vytvořte a pošlete sem funkční příklad, který si může každý vyzkoušet a uvidět na vlastní oči, že tam je problém. Věnujete tomu těch pár minut a zvedenete onu rukavici?

                      1. David Grudl

                        Re: bezpečnost?
                        Tak to už je trošku nefér.

                        Jednak, Filip má naprostou pravdu, že argument týkající se XSS je vůči DOM lichý. Protože jsou to právě šablony, kdo prostor pro tuhle díru vytvářejí.

                        Stejně tak může existovat kód, který uvede parser v omyl, ať už jde o parser v browseru nebo v šablonách. Řešením je být striktní a nic jiného než well formed HTML neakceptovat (a negenerovat).

                        A nakonec, není šťastné používat slovo „lhát“ tam, kde patří „mýlit se“. Pokud se třeba v Latte najde chyba, rád ji opravím, ale nedělá to ze mě lháře, dokonce ani mýlícího se, neb jsem nikdy netvrdit, že je to 100% bezchybné.

                    5. Martin Hassman

                      Re: bezpečnost?
                      „Bezpečnost v případě DOMu nebude horší, to je celkem jasné.-Mně to také připadá jasné, ale článek vyznívá přesně opačně“

                      Dobrý šablonovací systém bude mít stejnou bezpečnost jako DOM (nenapadá mne teoretický případ, kdy by ji měl větší). Onou větší bezpečnostní šablon se (běžně) myslí oproti stávajícím postupům a la skládání stringů nebo obecně jakýmkoliv postupům, ve kterých nedochází k automatickému escapování (což je nejčastěji právě ono skládání stringů – v různých podobách).

                    6. Martin Hassman

                      Re: bezpečnost?
                      Hergot, to vnořování komentářů je příliš omezené a vyvolává to zmatky (opravíme).

                      Davide, já Filipovi srovnání s XSS nijak nerozporuji. A lhát vs mýlit se je na hlubší debatu, kterou zde rozjíždět nechci.

                    7. Ondřej Žára

                      Re: bezpečnost?
                      Toto vlákno již skutečně ztratilo na přehlednosti. Předně se v něm ale dle mého názoru ztratila podstata jeho vzniku, a to vzájemné nepochopení principu escapování v JS šablonách.

                      Filip zcela korektně poukazuje na to, že „kontextově“ escapovat fragmenty HTML na úrovni stringu není možné, právě s ohledem na nejednoznačnost kontextu.

                      Filipe, nejčastěji používané JS šablony ale fungují na mnohem prostějším principu – jsou zcela bezkontextové a všechny stringy paušálně proženou převodem vyjmenovaných znaků na entity, hotovson. Pokud si to uživatel explicitně vynutí, žádné escapování se nekoná – a hotovo: buď vše, nebo nic.

                      Toto je mimochodem také jedna z partií šablonovacích systémů, se kterou mám koncepční problém. V tomto směru mi řádově více vyhovuje přístup, kdy direktivou změním bloku šablonového kódu jeho „content type“, tj. escapovací algoritmus. Jednak je tato změna aplikována na všechna nahrazení v bloku, druhak je možno provádět nějakou parametrizaci, tj. nabízet celou řadu takových escapů – ne jen „HTML entity“ a „nic“.

                    8. David Grudl

                      Re: bezpečnost?
                      A přesně tak funguje i kontextové escapování, jako je v Googlích šablonách a v Nette Latte (o jiných nevím). Jen místo speciální direktivy jednoduše napíšeš třeba HTML značku SCRIPT a kontext se v něm přepne. Prostě víc user friendly řešení.

                    9. Ondřej Žára

                      Re: bezpečnost?
                      …a pokud tedy otevřu značku SCRIP> a v ní ještě nějakou haluz (jak psal Filip, nejednoznačně uzavřený komentář či tak něco), kdo mi jednoznačně řekne, které escapování zrovna systém použije? Jistě to ten systém bude dělat deterministicky a dle platné dokumentace, ale padá tím bijekce escapování na interpretaci v prohlížeči (páč tam to každý může udělat jinak).

                    10. Filip.Jirsak

                      Re: bezpečnost?
                      Ať jsou šablony jednoduché bezkontextové, nebo se snaží automaticky rozpoznávat kontext, vždy mají nějaké limity – kód, který už neodhadnou správně, a pokud ho programátor extra neošetří, zůstane v programu bezpečnostní díra. Což je pro mne ten největší problém – automatické escapování má sloužit k tomu, aby na to programátor nemusel myslet – jenže zároveň by měl umět rozpoznat ty problematické případy, tedy by měl na escapování myslet neustále a vedle způsobu zpracování v prohlížečích ještě znát způsob zpracování v parseru šablon.

                      Jednu bezpečnostní výhodu automatickému escapování (oproti ručnímu) přiznávám: čím lepší automat, tím je statisticky menší pravděpodobnost, že se v daném programu objeví zapeklitá šablona, se kterou si neporadí.

                      Z tohoto důvodu podle mne ani sebelepší escapovací systém použitý v šablonách nebude nikdy tak bezpečný, jako DOM. Může se mu limitně blížit – ale pořád hrozí, že se někde objeví nějaký webový prohlížeč, který bude mít jiný parser a nějaký chybný kód bude interpretovat jinak. Představte si to třeba na podmíněných komentářích v MSIE. Před jejich příchodem mohl escapovač klidně předpokládat, že uvnitř HTML komentáře stačí escapovat dvojpomlčky. Od MSIE 5 ale najednou můžete mít uvnitř komentáře třeba JavaScript.

                      Jinak problém s escapováním byl třeba i v PHP a escapováním MySQL dotazů. A to je SQL jednoduchý jazyk a cílový parser je ten jediný v MySQL serveru. Přesto se nepodařilo udělat parser v PHP tak, aby dával za všech okolností přesně stejné výsledky jako ten v MySQL – čímž se otevřel prostor pro SQL injection. Nedělám si iluze, že v případě HTML by se to podařilo.

                    11. Filip.Jirsak

                      Re: bezpečnost?
                      David Grudl: pokud si nějaký escapovací systém bude myslet, že po libovolném výskytu </ ve skriptu je zase v HTML, myslí si to jinak, než nejpoužívanější prohlížeče. Pokud jste nemyslel výskyt </ v určitém kontextu skriptu…
                      <script>
                      console.log("</");
                      console.log("Stále jsme ve skriptu.");
                      </script>

                    12. David Grudl

                      Re: bezpečnost?
                      Chtěl jsem napsat automatické escapování má sloužit k tomu, aby na to programátor nemusel myslet – jenže zároveň by měl umět rozpoznat ty problematické případy

                      Zatímco bez automatického escapování musí programátor správně rozpoznat vše, vždy a bez jediné chyby. V praxi se proto ukazuje, že je řádově větší pravděpodobnost, že programátor zapomene nebo špatně nastaví kontext ručně, než že to udělá špatně automat. Proto je taky XSS stále nejrozšířenější dírou. (Ale nikoliv s Googlími a Latte šablonami).

                      > Z tohoto důvodu podle mne ani sebelepší escapovací systém použitý v šablonách nebude nikdy tak bezpečný, jako DOM.

                      Tak teď už se v tom trošku motáš, řeč je o šablonách, nikoliv DOM. Viz http://www.zdrojak.cz/clanky/javascriptove-mvc-frameworky-reakce-na-clanek-ondreje-zary/?show=comments#comment-24402

                      > Představte si to třeba na podmíněných komentářích v MSIE. Před jejich příchodem mohl escapovač klidně předpokládat, že uvnitř HTML komentáře stačí escapovat dvojpomlčky. Od MSIE 5 ale najednou můžete mít uvnitř komentáře třeba JavaScript.

                      Když jsi teda znovu otevřel téma DOM, ukaž mi prosím, jak v DOM řešíváš podmíněné IE komentáře obsahující HTML a JavaScript.

                    13. David Grudl

                      Re: bezpečnost?
                      errata: (nechápu proč to tu žere znaky)

                      Chtěl jsem napsat automatické escapování má … (a dál pokračuje tvůj citát)

                    14. David Grudl

                      Re: bezpečnost?
                      Kurva, na to kašlu.

                      Prostě to slovo SKRYPT se mi tu požírá, pak se mi požírá odřádkování, odrážka atd.

                    15. Filip.Jirsak

                      Re: bezpečnost?
                      Myslel jsem, že se tu celou dobu řeší, zda je DOM oproti šablonám (s automatickým escapovánímodolnější vůči XSS útokům (jak tvrdím já), zda je odolnost srovnatelná (jak tvrdí Martin Hassman), nebo zda jsou odolnější šablony (jak tvrdí Daniel Steigerwald v článku).

                      Podmíněné komentáře při manipulaci s DOMem neřeším, použiju místo toho if přímo v JavaScriptu.

                      To rozpoznávání problematických případů je přesně to, co podle mne v praxi nebude nikdy pořádně fungovat. Souhlasím, že automatické escapování je většinou lepší než ruční escapování. Ale trvám na tom, že ještě daleko lepší řešení – a jediné, které může bezpečnost opravdu zaručit – je takové, kde žádné escapování vůbec není potřeba. Což jde mimochodem udělat i s pomocí šablon – akorát to nebudou šablony s volným textem, ale šablony, které na výstupu generují DOM. Nejrozšířenějším příkladem jazyka pro takové šablony je XSLT.

  4. Širo

    Nesúhlasím ...
    Nesúhlasím vo veľa veciach a tobôž sa mi nepáči ukážka TodoMVC v EsteJS, pretože na takú malú ukážku Todo listu je nejako priveľa JavaScriptových súborov, nie?
    http://este.jit.su/client/deps.js

    Myslím si, že toto sa nikdy nestane: „AngularJS … co bude jednou součástí nativního api prohlížeče …“ … To sa nepodarilo ani jQuery a neverím, že také niečo ako AngularJS bude natívnou súčasťou prehliadača. Ak tak – tak maximálne Google prehliadača.

    1. Daniel Steigerwald

      Re: Nesúhlasím ...
      Deps obsahuje všechny potenciálně použitelné soubory, ne jen ty nutně použité. Generuje se automaticky, takže není třeba ručně udržovat cesty k souborům.

    2. Daniel Steigerwald

      Re: Nesúhlasím ...
      Až na to, že už se to stalo. MDV, které principem vychází z Angulařích šablon, už je součástí Chrome Canary. Ostatní prohlížeče budou následovat nebo dostanou polyfil.

    3. Širo

      Re: Nesúhlasím ...
      Ospravedlňujem sa, zle som to prečítal … Ja som nemyslel na šablony AngularJS, ale na celý framework AngularJS … v článku je napísané „že používá něco“, takže pardón.

  5. David Grudl

    Routing
    > Například routing. Ten mimochodem naprostá většina MVC frameworků řeší špatně.

    Co myslíš tím špatným routingem? Je ten odkaz správně, na odkazové stránce se totiž termín routing (ani nic, v čem bych zaznamenal souvislost) nevyskytuje.

  6. Daniel Steigerwald

    Jde o tento článek https://medium.com/joys-of-javascript/4353246f4480 Termín související s routingem má dokonce v názvu „Beyond pushState“. pushState (a hashchange) se pro routing klientských apps používá. Stručně o co jde. Naprostá většina JS MVC frameworků na změnu url prostě jen vymění jeden div element za jiný. To je ale málo a má to dost nešťastné UX konsekvence. Když jsem kdysi implementoval routing, ještě před existencí Este, hrozně mne štvalo takto naivní řešení. Příklad, klikneš na jeden odkaz, MVC rovnou zobrazí novou stránku, a na ní se začne něco načítat s progress barem. Co když se nic nenačte? Co když si kliknul špatně, a chceš ještě před dokončením načítání kliknout jinam? V Este každý presenter vrací promise, aby tak mohl dát vědět, jak načítání stránky dopadlo. Příklad http://este.jit.su/bower_components/este-library/demos/app/simple/#/product/1
    Dan Pupius, mimochodem jeden z autorů Closure, teď už mimo Google, tento pattern nazval Pending navigations – Block UI rendering until data is loaded. Další věc je udržení scroll pozice, něco, co Twitter vesele ignoruje už roky. Pokud vlezeš na detail, chceš aby tě back button vrátil na předchozí scroll pozici, ne na začátek. Atd. Este neřeší všechno v článku zmíněné, nicméně postupně tam zbývající body doplňuji. Hodně mi v tom pomáhá, že Este routing je async by default.

    1. David Grudl

      Re:
      Aha, nenapadlo mě, že v JS se pod routingem rozumí i samotné zobrazení předchozí stránky. Očekával bych, že tohle bude mít na starosti MVC, podobně jako když klikneš na novou stránku.

  7. Filip Procházka

    Rozbité odkazy
    Tip pro Dana a redaktory Zdrojáku: Když vkládáte odkazy na github do článku, zkuste je zafixovat na nějaký aktuální commit. Všechny Danovi odkazy na este jsou rozbité.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://zdrojak.cz/?p=8149