Přejít k navigační liště

Zdroják » JavaScript » Mají budoucnost šablonovací systémy v JavaScriptu?

Mají budoucnost šablonovací systémy v JavaScriptu?

Články JavaScript, Různé

Co jsou to šablonovací systémy v JavaScriptu? K čemu se hodí a kdy je použít? Z jakých nástrojů si můžeme vybrat. Na to se alespoň částečně pokusí odpovědět tento článek.

Dnešní článek patří do rubriky Subjektivně. Jejím cílem je zejména poskytovat prostor pro názory a pohledy na aktuální dění v oblasti webových technologií i na jejich vývoj do budoucna. Jedná se o osobní názory, které se nemusí vždy shodovat s názory redakce. Pokud máte co říct, pojďte k nám psát Subjektivně.

AJAX někdy použil snad každý (a kdo tvrdí, že ne, ten ho používá dodnes). Objevuje se několik scénářů s jeho použití, stále častěji ovšem narážím na následující scénář (kupříkladu v seriálu Davida Grudla zde na Zdrojáku):

  1. Webová stránka na základě události vytvoří AJAXové volání na server.
  2. Server vrátí data ve formátu HTML.
  3. Webová stránka přijatý fragment HTML zobrazí.

Od začátku mi tomhle řešení připadlo svým způsobem nečisté. Ať už proto, že se zde obvykle neprovádí žádná kontrola přijatých dat (obdrží se fragment HTML, který „cosi“ obsahuje a ono „cosi“ se vloží kamsi do stránky). Ale i proto, že v takovém nemohu pracovat s daty, ale jen s jejich HTML výstupem  (pokud budu chtít použít stejnou AJAXovou službu na jiném webu, možná i na jiném místě webu stávajícího, je docela možné, že budu muset návratový HTML kód mého AJAXového volání trochu upravit, aby vyhovoval nové stránce).

Jako příklad si můžeme uvést anketu (a už jsem takové viděl), u které při hlasování uživatele dojde k AJAXovému volání na server a přijetí fragmentu HTML, který obsahuje kód HTML celé ankety v odhlasovaném stavu (tj. kód celé ankety se zobrazenými výsledky), a ten se vloží do stránky.

Jenže, jak to vyřešit líp?

Šablony v JavaScriptu

Zbystřil jsem, když jsem loni zaslechl o používání šablonovacích systémů v JavaScriptu. To mně totiž hned připadlo jako vhodné řešení.

Jak to funguje? V případě ankety zmiňované výše by odpověď serveru obsahovala data, např. ve formátu JSON (budou to opravdu jen data obsahující výsledky jednotlivých hlasování ankety, bez jakéhokoliv HTML kódu), na ty na straně prohlížeče aplikujete šablonu a vygenerovaný výstup vložíte do stránky.

Má to smysl? V případě, kdy AJAX na stránce používáte maximálně jen pro vyřešení takové ankety, je ve výsledku celkem jedno, které z uvedených řešení použijeme a nejspíš zůstanete u původního – obvyklejšího – řešení. Pokud ovšem plánujete vaši aplikaci na AJAXu postavit (lidově řečeno „aplikace typu Gmail“), pak se jistě vyplatí použití takového šablovacího systému minimálně zvážit.

Dalším krokem může být vložení validace dat mezi AJAXové volání a zobrazení výsledku. K tomu můžeme použít např. mechanismus JSON Schema (obdoba schémat z XML), který si pomalu nachází cestu do javascriptových frameworků. Tenký klient na straně prohlížeče nám v takovém případě maličko „ztloustne“, ovšem pokud tvoříte opravdovou RIA, tak se zmíněnému ztloustnutí stejně nevyhnete.

PURE – jednoduchý javascriptový šablonovací systém

Jedním ze systémů, které podporují šablony v JavaScriptu, je projekt PURE. Jedná se o jednoduchou knihovnu, která má podporu pro frameworky jQuery, MooTools a Prototype. Jeho základ tvoří metoda autorender, kterou si hned předvedeme. Mějme v dokumentu umístěn následující kód HTML:

<div id="output">
  <div class="item1">...</div>
  <div class="item2">...</div>
</div> 

Do něj můžeme vložit data (nebo přepsat data stávající) pomocí volání:

$("#output").autoRender({"item1" : "nějaký text", "item2" : "nějaký text" }); 

Argumentem funkce autoRender jsou data ve formátu JSON, které nám vrátilo nějaké AJAXové volání. V našem případě došlo přímo k nahrazení dat ve vybraném úseku stránky (data se na správné prvky napárovala pomocí hodnot atributu class). Můžeme ovšem použít i vlastní připravenou šablonu, kterou předáme metodě jako druhý parametr. Představení dalších možností PURE včetně snadné práce s tabulkami nebo vnořenými seznamy najdete v dokumentaci nebo na blogu projektu.

Domplate – šablonování ve Firebugu

Dalším javascriptovým šablonovacím systémem je projekt Domplate. Ten sice v jeho aktuálním stavu nebudete moci použít (funguje pouze ve Firefoxu, ačkoliv autoři přislíbili podporu dalších prohlížečů), přesto by mohl ukazovat směr, kterým se javascriptové šablonovací systémy mohou vydat, a proto si jej krátce představíme. Domplate pochází od tvůrců Firebugu, kteří jej používají v rámci Firebugu pro dynamicky generované části rozhraní.

Domplate na rozdíl od projektu PURE zavádí vlastní šablonovací jazyk, zápis šablon může vypadat následovně:

var template = domplate(
{
    tag:
        DIV(
            SPAN("Nějaký text: "),
            SPAN("$object.item1"),
            BR(),
            SPAN(class: "bold", "$object.item2")
        )
}); 

Všimněte si, že na rozdíl od projektu PURE, který pro označení míst v šabloně používal class atribut HTML, obsahuje Domplate vlastní mechanismus a na class se nespoléhá. Obsahuje dále podporu vnořených šablon, cyklů s možností tvorby vlastního iterátoru a další zajímavosti.

Domplate si můžete vyzkoušet online. Pokud vás projekt zaujal, více se o něm dočtete na blogu  Software is Hard od českého autora.

Další možnosti

Oba zmíněné příklady byly jen úvodem do problematiky. Existuje řada dalších projektů, které zmíním alespoň odkazem. Trochu podobný způsob jako project PURE zvolil i autor projektu Chain.js a spoléhá se na párování dat pomocí atributu class. Autoři systému jTemplates šli cestou vlastního jednoduchého šablonovacího jazyka obsahujícího mj. instrukce pro tvorbu cyklů nebo volání vnořených šablon. Součástí projektu TrimPath je projekt JST (JavaScript Templates), který obsahuje šablony s instrukcemi nejen pro tvoru cykly, ale také instrukce podmínek pro větvení kódu. Mezi další šablonovací systémy patří JStemplate a Patroon.

Budoucnost

Je vidět, že šablonovací systém v JavaScriptu řadě vývojářům chybí (jedná se ostatně o přirozenou evoluci související s častějším a častějším používáním AJAXu a přenosu části logiky ze serveru na klienta). Prohlížeče takový systém nenabízí, a proto si vývojáři tyto systémy sami vytváří.

Na druhou stranu přestože šablonovacích systémů existuje celá řádka, nemám pocit, že by jejich používání bylo příliš časté. Vlastně nevzpomínám si, že bych při zkoumání kódu nějakého projektu na používání javascriptových šablon kdy narazil. (Kromě již zmíněného Firebugu a prohlížeče Google Chrome – ta jeho část, která je postavená na JavaScriptu, šablony využívá, jak se v něm můžete sami přesvědčit, např. na stránce „view-source:chrome://new­tab/“.) Sám jsem zvědav, zda se to změní.

Šablonovací systémy jsou na tom dnes podobně jako javascriptové frameworky před několika lety. Existuje jich hodně, ale zatím se nevyprofilovaly ty hlavní, u kterých bychom mohli očekávat jistou spolehlivost a další vývoj. Pro vývojáře tak není snadné zvolit, který ze šablonovacích systémů vybrat, což je jistě mínus.

Na druhou stranu tu je vždy i další možnost, a to napsat si šablonovací systém vlastní. O tom, že se může jednat o slabých několik desítek řádků kódu, vás možná přesvědčí John Resig ve svém článku JavaScript Micro-Templating.

Líbí se vám šablony v JavaScriptu?

Komentáře

Subscribe
Upozornit na
guest
37 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Darwin

Pro http://hashpage.com

Pro ukazku malou knihovnu sablon mam tady: http://github.com/…lib/snippets

Na jTemplates se mi libi vnorovani sablon do sablon.

Ma nekdo realne zkusenosti s PURE? Do porucite prechod?

tobik

V AJAXU jsem napsal spíše jen pár drobností, ale už od začátku
seznamování jsem považoval posílání HTML fragmentu a jeho přímé
zobrazování za něco špatného (nevím, co ve mě ten názor utvořilo :).
Proto jsem u jednodušších případů posílal jen samotné hodnoty a
u složitějších jsem je zabalil do XML. V obou případech jsem pak hodnoty
vkládal do stránky pomocí čistých DOM funkcí. Bylo to trochu pracné, ale
fungovalo to :)

jariq

S tvojim nazorom plne suhlasim. Klient by mal od serveru dotahovat len data
v XML formate – napoveda to aj X v nazve AJAX – a interpretacia tychto
dat ako je napriklad aj zostavenie HTML fragmentu by podla mna mala byt ulohou
klienta.

webdev

Dovolim si nesouhlasit podle me je to otazka ucelnosti. Jsou pripady kdy HTML
je jednoznacne efektivnejsi. Napriklad naplneni nejakeho divu textem. Naopak
jsou veci kdy JSON vede napriklad Datagrid.

Z hlediska jakehokoliv jineho nez pouzitelnosti to nema cenu resit AJAX tak
jako tak musi ty data posilat takze uz je jedno jestli poslu vysledek nebo ho
zbytecne budu posilat v XML a pak prevadet na HTML.

vlkoII

Celkom zaujimave moznosti templatingu ponuka asp.net ajax 4.0 [http://aspnet.codeplex.com/Wiki/View.aspx?…]
Aj ked to na prvy pohlad vyzera, ze to je zviazane s .net, nie je to celkom
pravda o templating sa stara js, ktory je od .net nezavisly, pretoze je urceny
aj pre asp.mvc. Ak bude pokracovat trend MS, tak je mozne, ze technologiu vydaju
pod os licenciou a potom by jej rozsireniu na ine platformy nemalo branit nic.
Viac o templatingu a dalsich zaujimavych binding veciach v: http://www.aspnet.sk/…-100858.aspx

vlkoII

Nevyhodou vyberu nejakeho js sablonovacieho systemu, je jeho zviazanost
s javascriptom. Kym generujem html na serveri nie je problem urobit stranku
tak, aby pri neexistencii javascriptu okolo toho html vlozila full page obalku.
Ak si uz ale vyberiem nejaky js templating a chcem podporovat aj nejs
prehliadace (typicky mobilne zariadenia) som nuteny robit view cast dvakrat.

mazarik

pouzivam vlastny sablonovaci system, ktory dokaze robit presne, to
co chcem

Srigi

Tiez rozmyslam, ze zacnem pouzivat vlastne sablonovacnie riesenie pre JS. Nemam ale chut robit veci zlozite, natahovat kB roznych libiek. Elegantne riesenie poskytuje samotny JS a jeho rozsirovanie prototypov. Odporucam urcite aspon vyskusat:

slajdy 100 az 103
http://www.slideshare.net/…ing-language

enjoy.

v6ak

Koukám, že chrome://newtab/ ani chrome://newtab/con­tent/ nepatří
Firefoxu, aspoň ne stabilnímu.

ra.ri.ta

Osobně nevidím jinou možnost pro efektivnější fungování HTML
stráněk než javascript.

Posílat stále objemné balíky dat je příšernost. AJAX je efektivní,
racionální a budoucnost. POST, GET A SESSION je stejna jak při HTML, tak
o co jde. JO asi to bude v té přístupnostri a v tom SEO, či jak se to jen
ta pitomost jmenuje.

blizz.boz

Ja som začínal s Ajaxom ešte v dobe keď (na Slovensku) ešte nikto
nevedel čo to je Ajax. Vytvoril som Joomla komponentu JoomlaComment ktorá
pomocou XMLHttpRequest komunikovala priamo so serverom.

A práve preto si myslím že JavaScript je cesta do pekla, JavaScript neni
plnohodnotný objektový jazyk a hlavne chýba mi v ňom statická typová
kontrola, interpretované jazyky IMHO nemajú budúcnosť vývoj v takomto
jazyku je oveľa pracnejší lebo vačšinu chýb nezachytí kompilátor, a
preto je aj omnoho drahší a aplikácie napísané v dynamickom jazyku sú
nespoľahlivé. JavaScript sa hodí maximálne na kontrolu formulára pred
odoslaním. Myslím že presúvanie aplikačnej logiky zo servera ku klientovy
je vývoj nesprávnym smerom.

webdev

Na to jsem cekal. JS memo objektovy jazyk. Cestina taky neni a prezila.
Nechapu jak nekdo dokaze objektovost povisovat na pouzitelnost. Nemyslim si ze
objektovost automaticky znamena dobry jazyk. Objektovost znamena jazyk, ktery
(teoreticky) dokaze psat prehlednejsi kod. Jinak neznamena nic vic. Dokonce ani
ona proklamovana cast, ktera udajne setri praci. Je sporna.

scorpi

Nedavno jsem to potreboval zaclenit do sveho vetsiho projektu, takze jsem si
delal porovnani javascriptovych sablonovacich systemu a jako nejlepsi reseni mi
vyslo EJS http://embeddedjs.com/ – moje
prakticke zkusenosti z pravidelneho pouzivani jsou velmi pozitivni…

Marek Soldát

Kdybych věděl, jak bude vypadat budoucnost, tak bych asi byl někde jinde,
nicméně doufám, že v šablonovacích systémech v JS to nebude.

  1. 1) Přístupnost, SEO, použitelnost z mobilu – to jsou všechno věci,
    které jsou s JS dost neslučitelné a narozdíl od předchozího
    diskutujícího si nemyslím, že jde o blbosti.
  2. 2) Zkuste si (na běžném uživatelském PC) v normálním prohlížeči
    otevřít 60 tabů stránek bez javascriptu a 60 tabů stránek
    s javascriptem, optimálně okořeněného flashovými bannery. Moje zkušenost
    je taková, že v druhém případě je celý systém tuhý víc, než jeden
    náš kolega po ránu, když ještě neměl kafe (zjištěný konverzní poměr
    je cca 10 tabů na –1 hodinu kolegova spánku). Zatímco v prvním
    případě, co se týče rychlosti, je systém stále lepší, byť jsem při
    provedeném testování kolegu zvýhodnil informací, že moje sekretářka má
    dneska minisukni. (pro potenciální rýpaly na téma, kdo si otevírá
    60 tabů najednou, bych rád uvedl situaci, kdy hledáte nějakou informaci,
    která zrovna není na 1. stránce v Googlu)
  3. 3) Je na čase začít důsledně rozlišovat pojmy „webová stránka“ a
    „webová aplikace“. Webové aplikace se často vyvíjí i s konkrétní
    znalostí toho, na jakých PC poběží, a představa, že někdo bude hledat
    adresu na přihlášení do firemního systému přes Google, je za
    střízlivého stavu poněkud nepravděpodobná. Tam potom oba dva předchozí
    argumenty pochopitelně postrádají praktického významu.
Marek Soldát

Jak si správně podotknul, při správném použití. Jednak si obecně
myslím, že tahle cesta správné použití není, ale diskutujeme tady obecně
o budoucnosti téhle myšlenky a ve mně se ozval varovný pud sebezáchovy.
(Předem se omlouvám za poněkud neformální charakter příspěvku.)

Řeknu Ti story, úplně to vidim. Píše se rok 2012. Jedu autem do nějakého
maloměsta, kde sem nikdy nebyl. Prší jak blázen, na ulici ani noha. Kam jedu
zapomenu, ale na webu mají přeci mapku. Adresu taky zapomenu. Tahám mobil,
googlim. Nic. Tak zkoušim domény. Trefím se (úplnou náhodou). A nic –
AJAX. Pořiďte si lepší prohlížeč.

Chápeš to, že já budu někde v ňákym vidlákově, v autě, leje jak
blázen, nevim kam mam jet a sem totálně v p*deli jenom kvůli tomu, že
nějakej rádobywebmaster kouzlil s timhletim?

Možná sem staromódní, ale přístupnost informace se pro mě rovná tomu,
že ji najdu na 486ce v textovym režimu a nejlíp telnetem na port 80 a ten
požadavek GET tomu serveru napíšu sám. Což zvládnu do chvíle, než bude
webová stránka pouhou aplikací, kde pro dostupnost informace je potřeba se
serverem komunikovat mandarínskou čínštinou.

Marek Soldát

Jenomze s mobilem, ktery plno lidi nepozna od PDAcka a prazskym signalem,
kde zvladneme pres 3G stahovat film od Cerneho mostu na Zlicin bez vypadku je
potreba se podivat na ruzne varianty jine: 

  1. Je tezke to vysvetlovat lidem v IT, to se musi videt, stale existuji lide
    vlastnici telefon s cernobilym displejem a na WAP se podivaj (kdo rika, ze
    nekoukal na jizdni rady ve WML, ten to dela dodnes).
  1. Byt zavisly pri prohlizeni jedne stranky na trvajicim pripojeni (typicky
    AJAX) nam nebude vadit, dokud se nedostaneme do mist s vypadavajicim signalem,
    nebo jeste lepe, nebudeme si je chtit stahnout do notebooku pro cteni v letadle
    (a myslim ze jeste hodne dlouho na svete najdeme spoje, kde nebude dostupne
    Wi-Fi). A pak je to jednoduche – kdyz bude iDnes v AJAXu a Lidovky
    „postaru“, ktery internetovy denik bude v letadlech ctenejsi?
Marek Soldát

Já jenom chtěl upozornit na to, že AJAX není samospásný a mělo by se
s ním jednat uvážlivě, což ty pochopitelně víš, ale u začátečníků
a některých dalších si tím nejsem zcela jist. Necháme toho :-)

v6ak

Dnešním mobilním prohlížečům Javascript moc nedělá problém, aspoň
jednodušší. V Opeře mini jsem si nechal zobrazit stolní Google
Reader a nebyl problém. Výkon může být problém, ale to se zlepšuje (JITka
apod.) a, jak říkáte, je potřeba rozlišovat mezi aplikací a stránkou.
Spustíte si někdy 60 desktopových aplikací?

scorpi

Presne tak – v opere mini jsem zkousel projizdet web (spis to byl
administracni system) postaveny na javacriptovych sablonach (EJS) a slo to –
po lehke optimalizaci to bude uplne bez problemu. Neni divu, kdyz je to prohnane
pres upravene jadro desktopove opery – vznikaji tak zajimave paradoxy,
v dnesni dobe si muzu napr. v Opere mini prohlidnout obrazky delane pres
canvas, coz si ale uz neprohlidnu ani pres dospely Internet Explorer (to ze
existuje i „emulace“ canvasu pro IE ted neni podstatne). Marek Soldat zjevne
nevychazi z reality, ale argumentuje fundamentalisticky.

David Grudl

K úvodním odstavečkům bych měl několik poznámek. Protože zdejší
redakční systém k**ví komentáře, budu se části snažit oddělovat reakce
alespoň řadou spojovníků.

  • – – – –

ad „Webová stránka na základě události vytvoří AJAXové volání na
server, server vrátí data ve formátu HTML, webová stránka přijatý
fragment HTML zobrazí“

_ Tento přístup má obrovskou výhodu. Aplikace na serveru totiž HTML
fragment vygenerovat umí, takže je neefektivní stejnou funkčnost duplikovat
na straně JavaScriptu. Zbytečná práce navíc, možnost zavlečení chyby,
v případě změny nutnost aktualizovat dvě místa.

_ Ano, jsou situace, kdy je lepší poslat data a z nich vygenerovat HTML
kód, typickým případem jsou třeba našeptávače. Ale tady se práce
neduplikuje – HTML podobu našeptávače totiž webový server obvykle
negeneruje, jde čistě o JS záležitost.

  • – – – –

ad „Od začátku mi tomhle řešení připadlo svým způsobem nečisté.
Ať už proto, že se zde obvykle neprovádí žádná kontrola
přijatých dat“

_ Všimni si, že žádná kontrola se neprovádí ani při použití JS
šablonovacích systémů.

  • – – – –

ad „…Ale i proto, že v takovém případě nemohu pracovat s daty,
ale jen s jejich HTML výstupem“

_ To není tak úplně pravda, třeba zrovna ve zmíněném Nette Framework
se zpravidla v jedné odpovědi odesílá obojí – JS data i HTML
fragmenty.

  • – – – –

ad „pokud budu chtít použít stejnou AJAXovou službu na
jiném webu…“

_ To nejde už kvůli bezpečnostní politice prohlížečů.

  • – – – –
webdev

Souhlas! Ac s Davidem obcas nemusism souhlasit, tak ted mi mluvi z duse.
A napsal jsem to i nize. Proste proc delat jednu praci dvakrat. Navic skutecne
JS neni zrovna nejrychlejsi ve vetsine prohlizecu by se dal pokladat naopak za
pomaly. Cim vic mu toho nalozime a parsovani do HTML z XML, je presne to co mu
nalozime zjistime, ze pak se aplikace skoro nepohne.

karmi

Ještě připomenu Template v Prototype: http://www.prototypejs.org/api/template,
který implementuje něco podobného jako ERB v Ruby. Ideální právě na
použití při zpracování JSON dat do stránky.

(Ale Prototype je asi beznadějně un-cool, co? :)

ll

to je docela dobrej figl s tim nosorozcem ten obrazek clanku, predpokladam
ze to je nejaky prebal knihy o javascriptu… takhle to na navstevnika tohohle
webu budi dojem ze pujde bud: za a) o clanek ktery je autorem te knihy, nebo za
b) o clanek ktery pochazi z te knihy, ale asi ani jedno neni pravda co?

b*d

Fragment HTML se používá protože innerHTML je daleko rychlejší, než
operace přes DOM. A je daleko jednodušší na implementaci.

Posílat XML? Vždyť posíláme validní (x)HTML, není to
totéž? KISS!

A pokud mám nějakou JS komponentu, pak dobře, ale ať má stabilní
data API.

Dobrý serverový framework pozná, jestli je dotaz AJAX nebo ne. Pak může
posílat fragment nebo celou stránku.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.