Ahoj,
jaký používáte šablonovací systém? Hledám nějaký, který je minimalistický, rychlý, bezpečný.
Twig mi nepřijde minimalistický, ale je rychlý a běžně používaný.
Smary je pomalejší než Twig (jsem se dočetl).
RainTPL?
Díky za připomínky a srovnání
MycroftH
a co Latte? Jako smary myslíš nejspíš Smarty, což je obrovská obludnost tahající historii celé civlizace. Twig je někdy sranda s něčím integrovat nebo rozšiřovat, debugování jeho kódu není občas pohoda.
Znas Dwoo? Zkus se mrknout - je to zajimavy a mnooohem rychlejsi nez napr. smarty
A co Blade od Laravelu? Oproti Twigu mi přijde hezčí, byť mám pocit, že Blade z Twigu vychází.
ak naozaj nutne potrebujes template engine tak Latte.. je stihly a vykonny.. smarty, twig su obludy
Tak já obecně se držím poučky používat to nejpoužívanější, tak jako tak to zaručí určitou míru funkčnosti, stability a kontinuity vývoje. V tomhle případě jednoznačně Twig (přešel na něj i Prestashop z původního Smarty).
Blade používám kvůli Laravelu častěji, ale přijde mi, že Twig je obecně elegantnější, lépe se v tom pracuje.
Nette (tj. šabl. systém Latte) je takové řešení "z našich luhů a hájů", tj. za mně, pokud nedostáhne celosvětového pokrytí jako Symfony, tak nee, ale vím, že to tu má spoustu lidí jako srdcovku.
Možná stojí za zmínku, že i samotné PHP lze použít jako šablonovací systém, už jsem to také párkrát použil, když pominu nějaké statické cachování (které lze dodělat, případně koupit Zend Server), tak bude jednoznačně nejrychlejší, byť nemá všechny funkce, co mají jiné systémy. Ale zase splňuje to, že je rychlý, minimalistický a bezpečný a ještě k němu nepotřebuješ žádné knihovny. :)
---------- Příspěvek doplněn 13.09.2019 v 12:22 ----------
Ještě bych dodal, že rychlost je dneska relativní pojem. Pokud je aplikace správně napsaná a běží na dobrých technologiích, tak rozdíly zrovna v rychlosti těch hlavních šablonovacích systémů moc velké nebudou. To máme cachování kódu v Opcache, pak nějakou cache pro objekty (Memcached, Redis), případně cache celých stránek až uť v souborovém systému nebo nějaké key-value databázi, celé je to pak přetažené CDNkou, které taky cachuje, využívání optimalizovaných externích úložišť pro statické objekty (obrázky, kaskády, skripty) a v neposlední řadě cache prohlížečů.
Vznikne z toho taková jedna velká megakeška, která rychlosti zpracování samotné kompilace hodně obrousí. :D
podle mě požadavek na rychlost je na místě, kdyby všechny ty věci nad php nebyly tak neskutečně pomalé (php 7 je již jinde), nemusí se na každé úrovni něco cachovat a pak bojovat s invalidací a jinými problémy.
Latte i Blade umí pěkně generovat připravené php soubory a již se nemusí znovu a znovu šablona parsovat jako to je v případě Twigu nebo smarty. Co si nějak pamatuji.
Muze mi tu nekdo dat konkretni duvody proc se pouzivaj sablonovaci systemy?Jakoze me legitimne zajimaji nazory zkusenych.
Ja uz dlouhy leta sablonuju v cistym php a nikdy sem nemel potrebu to delat jinak. Ale nemam zkusenost s velkymi tymy (desitky lidi a vic) nebo s tim, ze by sablony obhospodaroval nekdo uplne jiny nez junior programatori, takze si nejsem shcopen uplne predstavit jestli to v tehle prostredich nedava mnohem vetsi smysl...
ja pracujem tiez v cistom php.. sablony, nech su dokonale ako len chcu, budu mat vzdy obmedzujuci charakter..
za mě důvody:
- context escaping - nechci, aby vývojář musel řešit/znát/kontrolovat ošetřování speciálních znaků podle toho, kde bude výstup použit - jsou kritické rozdíly mezi xml, html, js, css/less, csv atd. atd.
- nechci, aby v šablonách byla byznys logika - řazení, filtrování, zvýrazňování, jednak z důvodu, že šablony často tvoří spíše neprogramátoři (kodéři) a také proto, že chci mít byznys logiku pod testy, šablony se blbě automaticky testují, stejně tak chci měnit šablony podle kontextu (překladu do jiného jazyku např.) a neduplikovat byznys logiku
- chci mít v šablonách co nejjednodušší syntaxi pro použití proměnných, je snažší vizuální kontrola a udělá se tam méně chyb zejména, když do nich zasahuji neprogramátoři
- chci mít možnost znovupoužívat připravené části (snippety), zanořovat je do sebe a mít ošetřené dynamické vkládání jiných souborů, aby nešlo vložit nic co neni povoleno
- chci mít jednoduchou možnost kontroly výstupu - validnosto html/xml, data masking atd.
- možnost použití maker pro generování konkrétních specializovaných struktur (např. pro snadný přechod na Google amp nebo obohacení značek pro nevidomé či třeba televize), tak abych to přímo v šabloně nemusel řešit při každém použití nebo dělat spousty variant šablon
Obecně se to dá asi shrnout do tří hlavních pilířů - bezpečnost, odolnost proti chybám a možnost kontroly výstupu.
Potřeba šablon vykrystalizuje při práci v týmu, předávání práce třetí osobě, vývoji rozsáhlých hybridních aplikací či snaze o výrazné zefektivnění práce a snížení počtu chyb.
Dobrý příklad z našich končin je Jakub Vrána a jeho adminer, píše dobrý kód a bez šablon. Osobně se mi líbí pojetí šablon v reactu nebo Razoru (asp.net).
TomasX: zrovna u te business logiky nejak nechapu, prece to ze to delas v php neznamena ze se k tomu nebudes chovat jako k sablone, tedy ze zadna logika do ni zkratka nepatri, posles si tam jen data k vypisu a tim to hasne, to same komponentovani, ktere jde taky uplne jendoduse zaridit velice podobnym zpusobem, jen proste misto nejakeho dalsiho jazyku jedes dal v php, ale jinak diky za seznam.
//React zboznuju :)
Jasně Aleši, když se dokážeš udržet a necpát do šablon co tam z principu nepatří, zvládneš vše i jen v čistém php.
Mně se na reactu líbí některé koncepce a myšlenky, nemám rád ale jeho realizaci, způsob jak řešení page rendering, nelíbí se mi některé moduly a nesedí mi moc komunita jeho vývojářů
TomasX: to co si popisal nema nic spolocne zo sablonovacim systemom (ok, okrem kontextoveho osetrovania), to sa riesi v inych vrstvach.. sablona patri do vrstvy, ktora ziskane data zobrazi, nic viac nic menej - ziadne data neziskava sama a ani nesmie vediet o existencii inych vrstiev, napr. ak sa bavime o popularnom vzore MVC..
ale ak budu sablony tvorit neprogramatori, tak tam su jasne vyhody sablon..
to byl můj pohled a vychází z projektů, které dělám a dnešní svět je živ nejen MVP/MVC. Je to opravdu různé a není žádoucí to zobecňovat a dělat z toho pravidla.
