Sablony v PHP jeste rychleji (diskuse)

[Josef Kufner]

Hehe, to jsem rád, že nejsem sám. Po přečtení nějakého z minulých dílů jsem ve svém posledním webu použil něco velmi podobného. Funkce render mi tedy rovnou vykresluje a do toho pole to ukládám přímo (nač ještě volat funkci?).

[deda.jabko]

prime vykreslovani taky jde, ale kdyz se to da do promenne jdou sablony elegantne skladat do sebe (cela stranka, hlavni formular, dodatecne formulare,...)

a funkce navic? prece jen je to objektove hezci. ;-]

[Josef Kufner]

Mno, šablony skládám pomocí include. Takže třeba šablona stránky s podnadpisem (h1 je v hlavičce spolu s navigací) a formulářem vypadá takto:

<?
include("page/header.php");
echo "<h2>Nadpis</h2>\n";
$d["form"]->render();
include("page/footer.php");
?>

Způsobí to, že šablon je potřeba trošku víc (pro každý typ stránky jedna), ale zas se s nima nemusím skládat v kódu a přijde mi to tak přehlednější i jednodušší.

[bazil]

a co budete dělat, až bude potřeba vypsat result z mysql? tedy vlastně z asociativního pole, ať už je jakékoliv? (jo vim, nacpat tam php foreach bo něco, ale je to značně hnusné a nepřehledné) a co třeba, když tam budou nějaké podminky pro vypisování ? a co třeba formuláře a tabulky, pořád je znovu klepat ... a hlavně templejtovací systémy se většinou snaží nejen oddělit logiku aplikace od zobrazování, ale také jednoduše dát grafikovi do ruky jazyk, z kterým může efektivne formovat vzhled stránek ... pokud člověk dělá projekt sám, tak to nějak nahackuje, ale jak se sejde víc lidí, tak je to už horší a btw už to dávno někoho napadlo ...

[Josef Kufner]

Není to ani hnusné, ani nepřehledné. A zrovna formuláře nejsou dobrý příklad – ty se mi osvědčilo řešit mimo šablonovací systém a nechat je, ať si obsluhují veškerou logiku sami. Někde jsem to tu už psal. Se vší parádou se obsluha formuláře scvrkne na jeho definici (1 řádek/widget) a jeden if (kreslit/zpracovat). Pokud se něco vykresluje častěji (tabulky), tak pro to prostě napíšu funkci a v šabloně ji použiju.

V tom tebou odkazovaném článku je to řečeno hezky. Cituji:

The ultimate goals of template engines shouldn't really be to remove all logic from HTML. It should be to separate presentation logic from business logic.

Prostě jde o to, aby tenhle bordel, který převádí datové struktury na HTML nestrašil, kde nemá. Mít v šabloně kus kódu, který jen vypisuje a případně i konvertuje data z nějakého pole do HTML není vůbec špatné, ba naopak, k tomu ta šablona je.

[bazil]

pokud šablony dělá programátor, a jeden člověk, co se orientuje i ve vnitřbostech programu ... koukněte se na teng, šablonovací systém seznamu ... ten je podle mě dobře vymyšlenej a ani nezavádí nějaké složité obskurdnosti do šablon a ani do kódu ... fpodstatě z tou myšlenkou byl navržen(btw na avc.sh.cvut.cz je přednáška). způsob šablonování, co tu uvádíte sem používal a ještě teď vlastně používám, ale rozhodně to chcu celé přepsat ...

[deda.jabko]

vyborne, ten clanek jsem neznal, ale jelikoz to jiz nekoho nezavisle na me napadlo, asi to nebude spatna cesta ;-]

problem s tabulkami, formulari jde resit velice elegantne, jelikoz jazyk php umoznuje deklarovat elegantne vlastni fce. (na rozdil od nekterych templatovacich enginu).... neni problem zavest neco takoveho:

function html_table_row($cells)
{
   $result = "<tr>\n";
   foreach ($cells as $cell)
       $result .= "<td>$cell</td>\n";
   $result .= "</tr>\n";
   return $result;
}

to si v kazde sablone staci inkludnout soubor s danyma standardnima funkcema (jeste mam nekolik variant pro praci - s ul, ol, li) a zacit je pouzivat. <?= html_table_row(array(1, 2, 3, 4)) ?>

[bazil]

ale tohle už je míchání php a html dohromady ... ale nevadí

[deda.jabko]

ale sablony nejsou o tom oddelit html od php, ale logiku aplikace od logiky prezentace. a je jedno jaky pouzijete jazyk... smarty, xslt, cokoliv jineho... taky michaji dohromady html a nejaky dalsi jazyk... shodou okolnosti je to v tomto pripade php...

[Lukáš Zapletal]

Rychlejší to nebude, většina šablonovacích systému šablony přeparsuje právě do něčeho podobného a uloží to do cache adresáře. Rozdíl bude max ve zjištění, jestli je cache soubor starší než soubor se šablonou

[deda.jabko]

nejde me ani tak o rychlost spis o to, ze se kazdy snazi vymyslet vlastni jazyky a to v pripade php zbytecne. pochopim to v pripade javy, c++, ktere nejsou na praci s textem ucelove stavene tak jako php.

[Daniel Kvasnička ml.]

Nedivim se vam, ze se vam ze Smarty zveda kufr, ale na XSLT mi nesahejte XSLT je jedna z (bohuzel) mala moznosti, jak pri sablonovani zustat u cisteho XML a neztratit jeho flexibilitu. Jinak zkuste PHPTAL, nejlepsi co jsem pro PHP nasel.

[deda.jabko]

na xslt vam klidne sahat budu, ale budte klidny na nic jineho uz ne ;-]

na xslt mne vadi to, ze je to de facto kompletni jazyk napsany v xml takze jeho syntaxe neni z nejpohodlnejsich a mnozstvi standardnich funkci je hodne omezene. na druhou stranu, pokud clovek potrebuje z jednoho xml udelat nejake jine xml, tak je to velice elegatni vec diky xpath. ale na web me to prijde jako docela sebevrazedna zalezitost...

z osobni zkusenosti pokud ma xslt template do 200 radku (malokdy) tak to jde, ale jak se to zacne blizit 500 radkum tak je to fakt bida a kod je docela neudrzovatelny....

[Daniel Kvasnička ml.]

Je to dost subjektivni, me XML nepripadne tak neprehledne.

Na webu mi to naopak pripadne obrovsky flexibilni a uzitecna vec. Predstavte si treba jenom XML sitemap a moznosti, ktere vyvstavaji z pouziti XSLT a XPath. Na ruzne publikacni systemy a blogy je to take paradni vec. Proc bych mel tahat data z DB, zpracovavat je v PHP/Pythonu a pak jeste posilat do procesoru templatovaciho systemu kdyz muzu zavolat XSLT procesor primo na datove zkladne a vysledek poslat? Fce v XSLT se daji rozsirit a treba EXSLT toho uz tak docela dost umi. Samozrejme to neni vhodne pouzit vsude. Jakmile mate slozitejsi vztahy mezi daty a delate nejaky CRM nebo neco podobneho, ukladat data pouze do XML by byly docela jatka.

[narg]

Pokud Vám chybí nějaké funkce, proč je nenapíšete v Javascriptu, Perlu, Pythonu (tedy záleží na XSLT processoru který používáte) nebo nepoužijete binding do jazyka ze kterého XSLT transformaci voláte? (Mno, pravda, nevím jak na tom jsou XSLT processory, ten v PHP myslím to neumožnuje, což se není čemu divit, protože PHP neumožnuje spoustu věcí, ale např. XALAN umí binding do Javy, 4Suite XML umí binding do Pythonu atp.)?

[Daniel Kvasnička ml.]

Kdyz jsem objevil 4Suite, byl jsem nadsen jeho funkcionalitou (existuje jina pythonska implementace XUpdate?). Ale kdyz jsem videl benchmarky, ve kterych byl beznadejne nejpomalejsi, muj zajem ochladl. Zajimalo by me jak je na tom ted.

[Goffix]

Teď jak to tady pročítám, tak mně napadla další výhoda XSLT. Co když začnu psát aplikaci např. v PHP a po čase bych ji chtěl přepsat např. do Javy? Sablony zůstanou! Ale pokud bych to psal pomocí šablon v PHP (nebo čemkoli jiném), nebo přímo pastnul do kódu, tak můžu začít od nuly vše. Neptej se mě proč by si to měl dělat, ale jestli si dobře vzpomínám, tak například Abíčko taky nebylo vždycky v Javě .

Jinak ten tvůj způsob jsem chtěl taky dřív používat ( než jsem objevil XSLT ), ale postupně to začíná být dost nepřehledné. Ber to takhle, co když ti najednou na serveru zakážou "short_open_tag" . Můžeš to začít přepisovat a pak se podívej na ten kód, jak je "přehledný" .

[Josef Kufner]

Ber to takhle, co když ti najednou na serveru zakážou "short_open_tag" . Můžeš to začít přepisovat a pak se podívej na ten kód, jak je "přehledný" .

sed -i 's/<\?=/<?php echo/g' *.php

[Goffix]

Puvodne jsem za to "prepisovat" chtel napsat do zavorky "nahradit", ale pak jsem to vypustil, jelikoz mi slo o sdeleni na konci te vety - "a pak se podívej na ten kód, jak je "přehledný" ."

[Daniel Kvasnička ml.]

Neptej se mě proč by si to měl dělat, ale jestli si dobře vzpomínám, tak například Abíčko taky nebylo vždycky v Javě

No pokud vim, tak vsechny tyhle nase komentare jsou XML ulozeny v DB. Jestli to Leos zene ke klientovi pres XSLT nevim, ale nedivil bych se.

[deda.jabko]

vsechny tyto uvahy jsou hodne hypoteticke.... vyzkousel jsem spoustu systemu na "delani prezentacni logiky", a abych pravdu rekl zadny idealni jsem zatim nenasel. zkousel jsem templatovaci knihovny pro php, javu dokonce i delphi nebo i nezavisle xslt a to v ruznych obmenach at uz proste sablony nebo pokrocily objektovy model ala VCL nebo ASP.NET.... pokazde bylo vhodnejsi neco jineho - neco jineho je web s hambatyma obrazkama a neco informacni system, kazde ma uplne jine naroky.

nekolikrat jsem vyse uvadel, ze ten kod neni nic svetoborneho, ale na male veci se to docela hodi a na velke veci se nehodi php (teda zalezi, na co si troufnou programatori) tak neni co resit ;-]

btw. kdyz se neco zacina prepisovat, tak je potreba, aby zakaznik mel potrebu koupit novejsi verzi... takze se nejdriv prepisuje prezentacni logika, pak aplikacni a v nejhorsim i nejake to skladovani dat...

[Kyosuke]

Teď jak to tady pročítám, tak mně napadla další výhoda XSLT. Co když začnu psát aplikaci např. v PHP a po čase bych ji chtěl přepsat např. do Javy? Sablony zůstanou!

Mně zase napadla další výhoda Lispu. Co když začnu psát aplikaci např. v PHP a po čase bych ji chtěl přepsat např. do Javy? Sablony zůstanou! Ale pokud bych to psal pomocí šablon v PHP (nebo čemkoli jiném), nebo přímo pastnul do kódu, tak můžu začít od nuly vše.

[paranoiq]

Mně zase napadla další výhoda Pythonu. Co když začnu psát aplikaci např. v PHP a po čase bych ji chtěl přepsat např. do Javy? Sablony zůstanou! Ale pokud bych to psal pomocí šablon v PHP (nebo čemkoli jiném), nebo přímo pastnul do kódu, tak můžu začít od nuly vše.

btw: co když budu chtít vyměnit template engine?

[Goffix]

Nejak jsem vase dva komentare neprobral. Mozna je to tim, ze LISP neznam ani trosku a Python jsem pred par lety jen natuknul (ne na webu), ale pripada mi, ze XSLT je trosku o necem jinem nez Python a LISP.

[Kyosuke]

Nepobrali jste to oba, pokud si myslíte, že Lisp má blíž k Pythonu než k XSLT.

[Kyosuke]

Ještě jsem zapomněl dodat: XSLT přímo vzniklo z Lispu a je to na něm dost vidět (konkrétně DSSSL), takže prohlášení „XSLT je o něčem jiném než Lisp“ je asi tak informované jako „C# je o něčem jiném než Java.“ Podobnosti jsou až zarážející a je jich podstatně více, než rozdílů.

Nějaká pěkná čtení:

http://www.topxml.com/xsl/articles/fp/fp.zip

http://www.idealliance.org/papers/extreme/proceedings/xslfo-pdf/2006/Novatchev01/EML2006Novatchev01.pdf

Dynamicky typovaný funkcionální programovací jazyk, jehož základní datovou strukturou je hierarchický seznam prvků. V této struktuře jsou psány samotné jeho programy, takže mj. může transformovat i sám sebe, pokud je to zapotřebí. Safra, to je nějaké povědomé, kde já tohle už slyšel? Docela by mě zajímalo, do jaké míry se ty hardwarové akcelerátory XSLT podobají lispovským procesorům. Přinejmenším konceptuelně je to naprosto identická konstrukce: eval+apply natvrdo zadrátovaný.

[Goffix]

Tak jsem si neco prelouskal o Lispu a nejaky ty flamewary o LISP vs XML (XSLT) a zastavam se XSLT . Nic ve zlim, ale Lisp je masochismus .

A jinak, tady byla diskuse o templatovacich systemech v jazycich, takze porovnavani Lisp vs XSLT neni na miste. Hlavne by me zajimalo, jak bych udelal to co jsem rikal.

Mam aplikaci (web) v nejakem jazyku a leze mi z toho XML. Pomoci XSLT prekonvertuju na XHTML a jedu... Pak zmenim jazyk na jinej a porad muzu pouzit jiny objekty, ktery mi taky vygenerujou XML a sablony pouziju znova.

Jak nahradim XSLT Lispem? V PHP jsem zadnej objekt na lisp nenasel.

[Kyosuke]

No, mně napadla totiž takové věc. XSLT se mi konceptuelně líbí taky. Proti XML jako jazyku pro dokumenty v zásadě nic nemám, ale pro programy mi to přijde jako šílenost. Jelikož jsou však LISP a XSLT poměrně přímočaré ekvivalenty, mohou fungovat dvě zhůvěrilosti: a) Kompilátor transformací definovaných v Lispu do XSLT (výhody z mého pohledu: 1) pro mě () lidštější syntaxe vstupu a 2) výsledek bude běhat všude), nebo b) implementace XSLT využívající vysokého výkonu kompilovaného lispovského kódu – něco na způsob CL-PPCRE. (výhoda: 1) interoperabilita se stylesheety třeba veřejně dostupnými na Internetu, 2) možnost aplikovat XSLT nějak na S-výrazy a z toho plynoucí 3) wow faktor. )

Každopádně je to pěkná výzva. Budu teď muset pracovat s nějakým XML a přemýšlím, jestli není lepší načíst XML dokument prostě jako S-výraz. Rozhodně mi to je bližší.

[Goffix]

Jednim slovem ... BLAZEN

[Kyosuke]

Počkej, ty sis napsal v PHP a v Javě reader a rule-based system, který definuje pravidla pythonovským kódem? V Lispu je to triviální, poněvadž nemá syntaxi, ale psát se s parserem pro Python se mi nechce.