Proof of concept v šabloně nastavitelných šablon, anew latte makro {template}

Etch napsal(a):

Proč prostě jednoduše nepoužiješ dvě render metody v komponentě?? Tedy něco zhruba následujícího.

Diky za tip, avsak tady jde trochu o jiny smysl. Pozadavek je renderovat menu a to komkretni renderovani customizovat. Teeba pridat class k <ul> tagu, nebo popis polozky obalit navic do spanu…

Predstav si situaci, kdy jsi uzivatel aplikace, ve ktere mas moznost menit jen sablonu. Mas k dispozici komponenty, ktere by melo jit vyse popsany zpusobem customizovat.

Porad muzes vytvorit zcela novou sablonu, tu predat komponente a trada, ale je to moc prqce s vytvarenim souboru, uploadovanim pres interface aplikace a to jen proto, ze chces drobne upravit nastaveni.

Dalo by se to take chapat treba tak, ze vyvojar upravuje model a presenter a grafik muze ohybat jen template :)

Doufam, ze ted jsem to popsal srozumitelneji.

Ještě jsem to nezkoušel. Teprve se na to chystám, ale dříve než začnu, tak se rád ujistím, že nevynalézám kolo, nebo jestli to nejde snáze.

Každopádně díky za tip, co mám prověřit.

Editoval 2bfree (12. 12. 2014 9:06)

Pohled „jsi uzivatel aplikace, ve ktere mas moznost menit jen sablonu. Mas k dispozici komponenty, ktere by melo jit vyse popsany zpusobem customizovat.“:

Tady si nedovedu představit, že „běžný uživatel aplikace“ (zákazník) dokáže vůbec najít volání dané komponenty, natož aby byl schopen změnit:

{control menu, items => $items}

na třeba:

{control menu,
    'items' => array('http://test.cz' => 'Test'),
    'outerTpl' => '<ol>{:itemsWrapper}</ol>',
	'linkTpl' => '<a class="classname" href="{:link}">{:description}</a>'
}

protože aby věděl, co tam vlastně je možné vůbec nastavit, musel by lokalizovat šablonu dané komponenty a na to aby danou šablonu vůbec pochopil by musel zase mít aspoň nějaké základní znalosti latte. „Většina běžných uživatelů“ aplikace, které znám, nevědí ani co je <ol></ol>, natož aby přelouskali latte šablonu. :)

Pohled „Dalo by se to take chapat treba tak, ze vyvojar upravuje model a presenter a grafik muze ohybat jen template“:

Já rozumím tomu jak to myslíš, jen mi to nepřijde v praxi (myšleno v mém osobním případě) moc použitelné. Když si jen pomyslím, že bych podobným způsobem „omezil“ mojí kodérku a grafičku, tak mám pocit, že bych skončil do minuty zadupaný do země.

Samozřejmě si to dovedu představit na nějaké jednoduché úpravy, ale když se kouknu na ten uvedený příklad „menu“, tak ve chvíli kdy se do toho začne cpát {ifCurrent}, přiřazovat linkům nějaké ID, dividery, vnořené menu a podobné věci, už mi to přijde jako nepříliš ideální řešení.

Možná je můj pohled ovlivněn „vztahem“, který mám s kodérem, kdy já nechci dělat nějaký základní template a kodéra degradovat na ohýbače. Já se prostě o šablony nechci starat vůbec, protože to není moje práce. Kodérka dostane jen seznam přístupných proměnných a šablona je její práce. Ona maximálně vznese požadavek, že u dané komponenty musí jít jednoduše vyměnit šablony a to je zase moje práce tohle zařídit.

Existuje zde samozřejmě možnost, že by si pomocí podobného makra kódér nadefinoval šablonu sám, ale přijde mi to, jako by si tím sám sobě svazoval ruce.

Editoval Etch (12. 12. 2014 11:56)

enumag napsal(a):

Ono to velmi pravděpodobně fungovat nebude protože při ajaxu se šablona nespouští celá ale jen některé její části (invalid snippety a komponenty). Tzn. to tvé makro se nezavolá a komponenta se bude vykreslovat se špatnou šablonou.

Zdá se že komponenta musí mít šablonu rozhodnutou ještě před vykreslováním, což v praxi znamená že by se šablona komponenty nejspíše měla nastavovat v render metodě(?).

Nezbývá tedy než vyzkoušet. O víkendu tomu zkusím věnovat chvíli. Pak poreferuji.

Teď mě ale napadlo, že možná uvažuješ o krok dále než já, tedy že by byl snippet uvnitř takovéto struktury. tedy něco jako:

{capture $flashesWrapper}
	{snippet flashes}
		<div n:foreach="$flashes as $flash">{$flash->message}</div>
	{/snippet}
{/capture}
{template '{:$flashesWrapper}',  flashesWrapper => $flashesWrapper}

Tedy že by se vykreslilo jen to co je mezi {snippet} a {/snippet}. Tohle je zrovna jednoduchý příklad, který by se dal přepsat tak, aby byl snippet kolem celé komponenty, ale máš pravdu, že by v tom mohl být z dlouhodobého pohledu problém. Zkusím promyslet, kudy z toho ven.

Editoval 2bfree (12. 12. 2014 13:38)

matej21 napsal(a):

@2bfree nema cenu to zkouset, nebude to fungovat. Pokud je invalidovana pouze komponenta (a ne nejaky wrapper snippet), tak se vzdy zavola pouze render metoda bez parametru.

To je fakt, že na tenhle bug už jsem jednou narazil, kdy jsem měl komponentu vykreslenou přes {control component:list} a ono mi to v ajaxu zavolalo render() namísto renderList().

matej21 napsal(a):

@2bfree neni to bug, je to „known limitation“ :)

Ok, asi by tedy stálo za to tuto „feature“ zmínit v dokumentaci ke snippetům. Něco ve smyslu „Ano, Latte je super a komponenty skvělé, neb mohou mít více než jednu render metodu, ale tato technologie stojí a padá s ajaxem. Pokud chcete používat ajax a snippety, musíte mít pouze jednu render metodu.“

Na jednom projektu jsme tuto limitaci obešli tím, že render metoda ručně zavolala všechny ostatní render metody, kde by teoreticky mohl být snippet, což kupodivu funguje, ale asi by to stálo za menší časovou investici.

Narazil jsem na následující problémy a jejich řešení:

Pokud chci v šabloně definovat parametr, který chci použít ve snippetu, tak o něm snippet neví:

{default $testTpl = '<em>{:test}</em>'}

{snippet test}
	{!=strtr($testTpl, array('{:test}' => $test))}
{/snippet}

Toto se dá naštěstí obejít díky dostupnosti objektu $template

{if isset($template->testTpl) === FALSE}
	{?$template->testTpl ='<em>{:test}</em>'}
{/if}

{snippet test}
	{var $testTpl = $template->testTpl} {* Tohle je skoro zbytečné, jen kvuli ajaxu to zde zatim musi byt (vyřešeno v https://github.com/nette/application/pull/47)*}
	{!=strtr($testTpl, array('{:test}' => $test))}
{/snippet}

Pro vyšší přehlednost zvažuji na výše popsané vytvořit latte makro {varGlobal} a {defaultGlobal}

Když invaliduji snippet (zavoláním $presenter->redrawControl('test')), tak se nezavolá to co není ve snippetu.

Na to je jednoduché řešení popsané v dokumentaci k ajaxu tedy že to co chci při invalidaci načíst musím obalito do latte makra {snippetArea} a invalidovat jej společně. Tedy výše napsané by se zapsalo:

{snippetArea defaults}
{if isset($template->testTpl) === FALSE}
	{?$template->testTpl = '<em>{:test}</em>'}
{/if}
{/snippetArea}

{snippet test}
	{var $testTpl = $template->testTpl}
	{=strtr($testTpl, array('{:test}' => $test))|noescape}
{/snippet}

A invalidovalo by se to

$presenter->redrawControl('defaults');
$presenter->redrawControl('test');

Když si komponentu vykreslím přes jinou než render() metodu (jak ukazuje následující příklad), tak se vykreslí správně zavoláním $control->renderTest(), ale v ajaxovém volání ve snippetu se zavolá špatně $control->render() (jak bylo popsáno dříve)

{snippet test}
	{control test:test}
{/snippet}

Tento problém se řeší na několika místech forum , github a našel jsem i různé workaroundy na tento problém: dotblue

Řešení tohoto problému je podle všeho komplikované. Napadlo mě, že by se implementovala funkcionalita, že by šablona komponenty věděla, jakou render metodou byla volána (třeba manuálním zavoláním $control->template->renderedBy = __FUNCTION__, ) a při sestavování odkazu na akci by se název render metody přibalil k názvu komponenty. Což ale nejde rozumně zařídit bez zásahu do stávajících struktur Nette. Má vůbec smysl jít touto cestou, nebo jsem něco nedomyslel?

Poslední problém jsou samotné parametry komponenty předané z šablony:

{snippet test}
	{control test,
		test => $test
	}
{/snippet}

Toto sice krásně funguje při běžném vykreslení, ale při ajaxovém volání se defacto na zavolá $presenter->createComponent('test')->render() dříve než se zavolá render na presenteru (ostatně se ani zavolat nemusí) a tím pádem nemá vůbec ponětí, že by měl dostat nějaké parametry.

K tomuto mě napadlo, že při neajaxovém volání se parametry uchovají v cache a při ajaxovém se vyvolají.

Editoval 2bfree (17. 12. 2014 15:34)

@2bfree velice nebezpečný koncept, podle mě to je celé špatně. Šablony v šablonách jsou overkill. Rozbil jsi kontextově senzitivní escapování, automatickou ochranu proti XSS v odkazech, taky escapování javascriptu a css v properties elementů a bůhví co ještě.

Raději vymysli jak na to použít bloky. A nebo úplně nejlépe neřešit a používat pohledy v komponentách tak, že je budeš konfigurovat v továrničkách – to se s ajaxem slučuje skvěle.

Asi 10 minut jsem přemýšlel, jestli na tohle vůbec reagovat, ale protože téměř všechno escapování a ochrany tam máš opravdu mrtvé, musel jsem na to upozornit. To že to dělá MODX to neospravedlňuje.

toto macro zcela logicky vypíná content-aware escaping jelikož je vzhledem k potřebě HTML šablon nežádoucí

Nesouhlasím :)

Doporučil bych ti vyzkoušet, jestli by ty „mini“ šablonky nešlo prohánět přes Latte místo toho abys vynalézal vlastní šablonovací systém. Psát HTML do stringů a slepovat to do větších stringů je roky překonaný koncept.

Když bys to udělal „správně“, zapisovat by se to mohlo například takto

{var $userName => $user->getIdentity()->getId()}
{template $tpl}<strong>{$userName}</strong>{/template}

A to už jsme vlastně u toho, že zvnovuynalézáš {block} a {capture}, akorát horší, protože tam nemáš vyřešené escapování. Takže jsme zase u toho, že nechápu smysl.

Hele neber si to nijak osobně, tohle není útok, prostě říkám co si myslím. To máš úplně tu stejnou situaci, jako když by ti maminka 15 let tvrdila, že skvěle zpíváš a pak jsi šel do televize a skončil ve hvězdné pěchotě (teď mě napadlo, že to mohlo vyznít, jako bych tvrdil že neumíš programovat, to bych si nikdy nedovolil napsat a pokud by taková intepretace napadlo i tebe tak jsem to tak rozhodně nemyslel).

Budu rád, když mě vyvedeš z omylu.

Ono je asi potřeba se vrátit na začátek a říct si, co vlastně řešíš a proč to řešíš.

Co se týče komponent, napadá mě – co takhle používat extendování šablon? Ty svoje bloky které jdou změnit stejně označuješ. Co kdyby jsi to zkusit udělat už s tím, co latte v tenhle moment umí – pak se vyhneš všem nevýhodám, které jsem zmínil.

MODX znám jen od vidění, nevím jak funguje uvnitř. Dejme tomu, že si to ukážeme třeba na konceptu z wordpresu. Tam máš v šabloně „bloky“ nebo „sidebary“ kam si můžeš naskládat libovolné komponenty v libovolném množství a libovolném pořadí. Měl bys tedy nějaký konfigurátor, pomocí kterého označíš komponentu, jakože má být v daném „šuplíčku“, ve kterém se na webu vykreslí. Když už máš takový konfigurátor, tak ty komponenty nejspíš skládáš v presenterech do sebe dynamicky. Optimalizovat by se to dalo nejakým generováním kódu do tempu, ale to odbíhám.

To znamená, že přímo ovládáš jak se komponenta do presenteru vloží – tedy si s ní můžeš dělat co chceš!

public function actionDefault()
{
	foreach ($sidebarComponents as $meta) {
		// pro jednoduchost, z DIC si vytáhnu továrničku na komponentu
		$factory = $this->serviceLocator->getByType($meta->componentFactoryClass);
		$control = $factory->create();

		// dejme tomu, že máš třeba už v komponentě nastavenou její výchozí šablonu
		// takže uděláme to, že vezmene šablonu co nastavil uživatel v administraci
		// přidáme na její začátek {extends $originalTemplate}
		// a do $originalTemplate předáme cestu k původní šabloně
		// ten latteTmpStorage by měl vzít obsah latte šablony, uložit ji a vrátit cestu k souboru
		$templateFile = $this->latteTmpStorage->build($meta->templateContent, $control->template);

		// tuhle vygenerovanou šablonu pak můžeš nastavit té komponentě
		// akorát si ji nesmíš přepsat v render() :)
		$control->template->setFile($templateFile);

		// připojit k presenteru
		$this->addComponent($control, $meta->controlName);
	}
}

Tohle je samozřejmě jenom nástřel, ale díky podobnému mechanismu teď můžeš udělat třeba to, že máš nějakou výchozí šablonu

<ul n:block="users-list">
	<li n:block="username">{$userName}</li>
<ul>

a v administraci si pak vytvoříš vlastní šablonu

<li n:block="username"><strong>{$userName}</strong></li>

A mělo by to fungovat – změní se jenom ten malej kousek. Detaily určitě zvládneš doladit :)

Filipe, díky za nasměrování s tím {extend …} makrem. Ještě se na to musím trochu podívat, ale vypadá to, že tudy opravdu vede cesta.