Zajímavý, ale nějak nechápu, k čemu je to dobrý :)

Pokud mi najdeš lepší způsob, jak zpracovat např. data z databáze jako PHP soubor, tak k ničemu :-)

Máš třeba v DB stránku, která obsahuje HTML kód, a najednou je potřeba v tom HTML zavolat nějakou PHP fci. Musel bys data buď dočasně uložit a pak includovat (zdlouhavé a pomalé), nebo použít zmíněný trik. Koukal jsem, že rychlost je víc než dobrá.

Tenhle případ mě nenapadl, mám totiž vždy oddělen php a html kód šablonou. Ale pro tvůj příklad chápu, že je to více než užitečné.

[3] Taky používám šablony... a nakonec jsem se vrátil k úplně jednoduché "pseudo-šablonové" třídě, která neprovádí kompilaci. Šablony se tak vlastně už píšou v kompilované podobě - má to výhody:

1) není třeba hlídat, jestli je kompilace vždycky aktuální
2) není třeba vytvářet kompilační adresář a nastavovat mu přístupová práva
3) žádné zpomalení první kompilací
4) úplná kontrola nad kódem

Jedinou nevýhodou je, že šablona je trošku míň přehledná. Jenže mě nepřijde zase tak velký rozdíl mezi:

Smarty:
{$promenna|escape:'html'}
a
<?=htmlspecialchars($promenna)?>

když ten druhý zápis přináší tolik výhod. Ale je jasné že Smarty toho umí spoustu, záleží na programátorovi co si vybere.
Chci o tom napsat článek, proto jsem se tak rozepsal.

Smím se zeptat, který šablonový systém používáš?

Já používám vlastní šablonovací systém se syntaxí třeba pro proměnnou: {variable name='jmeno' /♀♀} Když si totiž tohle člověk navrhne a udělá sám, tak to má výhodu, že se kompilace nikdy nezdržuje věcmi, které v projektu nevyužiješ - třeba Smarty je se všemi svými volbami skoro nepomalejší systém na šablony.

Tvůj systém šablon má taky něco do sebe, tady hlavně záleží na tom, co zrovna vytváříš, jestli na tom dělá víc lidí... Když vezmu třeba tvoje výhody:

1) řeším smazáním příslušné překompilované šablony při změně dat
2) tohle podle mě není jeden z neřešitelnách problémů :)
3) první kompilace zabere (třeba u mě) v nejsložitější šabloně asi 10ms, ale pro všechny další přístupy už jenom pošlu na výstup běžný html soubor, což nezabere takřka žádný čas a ušetřím si připojování k databázi, provádění všech dotazů a výpočtů (v podstatě všechno), což je už hodně velké zrychlení
4) někdy výhoda a někdy ne - třeba když poskytneš zákazníkovi eshop s tím, že si může upravit vzhled šablonami a css, tak kdyby v nich měl plný přístup k php kontextu, asi by se mi to moc nelíbilo :)

Zkrátka je to hlavně o tom, jak rozsáhlý děláš projekt, ono se pro každou věc hodí něco jiného.

[5]
3) - když posíláš na výstup dál jen HTML, nejde mi do hlavy, jak u dynamických dat zjišťuješ kdy je třeba přerenderovat (tzn. kdy jsou nová), bez připojení k DB.

Jo radši píšu všechno na míru, vlastní, je to až chorobné :) Mimochodem, vsadím se, že to zakončení /♀♀} je kvůli tomu, aby preg_replace_callback neuzavřel proměnnou při výskytu '}' někde uvnitř v řetězci. Velké to trápení, vždycky záleží na kontextu kde se ten znak nachází :)

3) Nezjišťuji to vůbec, ale posílám vždy překompilovanou šablonu. A když se provádí změna dat v databázi (třeba přidání nového příspěvku pod článek), tak dotyčnou šablonu smažu.

No a zakoneční /} je spiš kvůli návyku na správnou syntaxi po vzoru XML :). Když mám znaky { a } v řetězci, tak je nahradím příslušnými entitami &#123; a &#125; a je po problému.

[7] To mě nenapadlo, zachytit změnu takhle. Bezva.

U zakončení mě zmátly ty znaky ♀♀ které se tam zřejmě vloudily omylem, ale přišlo mi to použitelné.

[2] Data z databáze jako PHP soubor by se dala zpracovat použitím funkce stream_wrapper_register(). Ale z bezpečnostního hlediska to je docela odvážné, lepší mi přijde nahrazovat jen povolené konstrukce.

[9] S tou databází jsem nedal nejšťastnější příklad. Tady bych to sice neváhal použít (a v budoucnu se tak stane), ale je pravda že mít PHP kód v DB je loterie.

Tohle mi sakra pomohlo...delal jsem si vlastni prekladovej system a potrebuju v urcitejch specialnich pripadech prohnat soubor vlastnim parserem pred poslanim uzivateli... Bez tohodle vec nemozna... Diky!

stará známá věc, ale!
- určitě nadávat do políček kam muže psát klient, nebo nedějbože uživatel ;o) to budete mít sql injekci během chvilky ;o)

IRSEef <a href="http://vvnfbzogtasd.com/">vvnfbzogtasd</a>, [url=http://knmbykibhcxe.com/]knmbykibhcxe[/url], [link=http://zjkvirbhpgly.com/]zjkvirbhpgly[/link], http://cfpngthtcvxp.com/

DPZf7F http://www.RUWE5gOde94HqsfDYIh3uBfJfSMdiDSG.com