Stránka Dědičnost šablon

PetrP

Trochu se bojím aby někdo nezačal psát šablony takto:

class FirstPage
{
    public function render()
    {
        $s  = '<!doctype html>' . "\n";
...

Tedy chtělo by to nějak zvýraznit že to je jen příklad.

Jan Tvrdík

Doufám, že každému dojde, že v těch šablonách je to o dost přehlednější. =)

Připsal jsem další dvě kapitoly. Uvítám jakoukoliv kritiku či nápady.
Zatím je to hodně raná fáze (chtěl jsem vypnout indexaci, ale nepřišel jsem, jak na to), ale přijde mi ta paralela s OOP pěkná na pochopení.

Michalek

Nevím, na jakou uživatelskou skupinu je stránka zaměřená (pokročilý, začátečník, …), ale kdyby šlo o mojí maličkost, prohodil bych 1. (php) a 2. (nette) část.

Když na stránku vlezu, chci vidět jak to vypadá v nette – když jsem chytřejší, pochopím jak to funguje. Fakt. Takhle musím jet někam doprostřed stránky, kde ani není vizuálně oddělené, že už jsme v nette.

Můj pohled… :)

gawan

Mne to tiež pripadá zbytočne zložité. Primárne ma nezaujíma logický postup ako sa dostať k správnemu riešeniu, ani ma nezaujímajú zlé riešenia, chcem len vidieť to najlepšie správne riešenie. Nič viac. Len „Best practices“.

Myslím, že celá dokumentácia by bola dobrá len v štýle „Best practices“ bez zbytočnej omáčky, dôvodov, zlých riešení. Výhoda by bola, že by to aj bolo skôr hotové a hlavne by to bolo prehľadnejšie.

Jan Tvrdík

Mířeno na začátečníky. Po přečtení by měli chápat a umět s dědičností šablon pracovat.

Otázka jde, zda to chtějí chápat a nebo zda to chtějí pouze používat, s tím, že pochopení (snad) přijde časem – při používání.

Odmazat celou paralelu na OOP je určitě možné, ale nejsem si jist, zda tím nepřijdeme o klíčovou část článku.

Jan Tvrdík

Takto to vypadá bez paralely na OOP: https://wiki.nette.org/…blon-bez-oop.

Fakt to takto někdo pochopí? Pokud by se k tomu dopsalo více textu, tak snad.

gawan

Mne sa to bez toho OOP páči viac, ten OOP príklad sa mi zdá trochu krkolomný. Predsa len si myslím, že ak aj niekto začína s nette, už asi vie, čo je to OOP.

Ak ak nie, možno by mohol byť v dokumentácii odkaz na všeobecné OOP, čo to je a z tejto stránky by bol len na to odkaz.

Áno, myslím, že dokumentácia by mala byť len vysvetlenie ako to najlepšie, najrýchlejšie použiť. Okrem toho sa to aj tvrdí v hlavných prednostiach nette, že má „strmou křivku učení“ ;-)

Jan Tvrdík

gawan napsal(a):
Ten OOP príklad sa mi zdá trochu krkolomný. Predsa len si myslím, že ak aj niekto začína s nette, už asi vie, čo je to OOP.

Ten příklad nemá za cíl vysvětlovat OOP. Má za cíl ukázat, že něco nového (dědičnost šablon) funguje stejně jako něco, co už zná (dědičnost v PHP).

muflon

Tiez si myslim ze bez toho prikladu s OOP je to prehladnejsie a zrozumitelnejsie. Ako nettte zaciatocnika ma to po prvom precitani dost zmiatlo sice na druhe som to uz chapal ale aj tak by som tam ciste oop neplietol.

Vyborna praca pokial budu clanky postupovat tymto smerom tak nette bude mat kvalitnu dokumentaciu.

LM

Nebyl by lepší obrázek? jen takovej nástřel:

Jan Tvrdík

Jsem jediný, komu se z toho obrázku zatočila hlava?

Honza Marek

Ten článek je napsanej dobře (hlavně bez OOP). To OOP je sice fajn příklad, ale jen pro dobrého programátora, který to má v malíku. To tady nejsou úplně všichni.

romansklenar

Obrázek je popisnější než několik odstavců textu.

22

A nebylo by lepší tedy použít v základu verzi bez OOP a na OOP rozšíření dát jen odkaz „pro zkušené“?

nAS

Mě se nejvíc líbí verze bez OOP a bez obrázku.

Myslím, že by to nejdříve chtělo rozhodnout, pro jak zkušené programátory to budeme psát. Protože každý alespoň trochu zkušenější programátor ví, co to je dědičnost a i z pohledu na tu zkrácenou verzi mu bude jasné, jak to funguje. Nevím jak vy, ale já nemám rád dlouhé popisné návody, kde se nudím – tam přeskakuju a pak můžu přeskočit i něco užitečného. Takže já bych šel spíš hutnější cestou.

pekelnik

Obrázek je prima :)
Odstavec o OOP je mimo ;)

Jakub Lédl

Pokud se někomu z těch šipek motá hlava, co zkusit na tom obrázku odlišit jednotlivé soubory barevným pozadím a změny defaultních hodnot vyznačit?

Např. parent.phtml bude celý zelený, child.phtml celý oranžový, výsledek bude zelený až na místa dosazená z child.phtml, která budou oranžová.

Filip Procházka

Souhlasím že verze bez OOP je srozumitelnější

_Martin_

Jakub Lédl napsal(a):

Např. parent.phtml bude celý zelený, child.phtml celý oranžový, výsledek bude zelený až na místa dosazená z child.phtml, která budou oranžová.

To by mohlo jít, ty šipky mě taky jen matou.

Jan Tvrdík

Očividně jsem jediný, komu se ta paralela na OOP líbí, takže ji asi zrušíme. Zrušením ale zároveň vznikne potřeba připsat více textu, aby byly patrné rozdíly např. mezi {block #myBlock}{/block} a {include #myBlock}.

Obrázkům, na které kouknu a vidím se nebráním. Nahradit šipky barvami je dobrý nápad.

Uvítám jakoukoliv pomoc s úpravami a rozšiřováním článku :)

_Martin_

Jan Tvrdík napsal(a):

Očividně jsem jediný, komu se ta paralela na OOP líbí…

Mě se taky líbí, ale uznávám, že by mělo být co nejméně textu navíc. Pro začátečníka je tohle dobré, protože mu to ukáže tu paralelu a tím se to lépe naučí. Pro někoho Nette znalejšího to je zbytečný text navíc, ve kterém bude špatně hledat, pokud ho zajímá rovnou fungování šablon. Možná tedy takovýto článek i s vysvětlením udělat samostatně do nějaké seriálu či tak (nějaké rozšířené info) a naopak do Příručky programátora dát čiště jen popis toho, co šablony umí (a samozřejmě to prolinkovat).

redhead

Nevím, ale když jsem to otevřel, tak se mi to ani nechtělo moc číst.. A jako začátečníka by mě to asi odradilo dokonale. Obrázek je myslím lepší, jednoduší a názornější řešení..

David Grudl

Jestli můžu přidat takovou zkušenost ze školení. Je lepší se na začátku vyhnout pojmům dědičnost a přepisování bloků a prostě jen hovořit o blocích a ukázat, co s nimi jde dělat v rámci jednoho souboru. Teprve v druhém kroku ukázat, že bloky se mohou objevovat jak v souboru „content“, tak v souboru „layout“ a že při stejném pojmenování se přepisují (ani tady nepoužít termín dědičnost). A nakonec zmínit, že nemusí být jen dva soubory „content“ + „layout“, ale že jich může být i více.

Tohle je z hlediska popisu dost složité téma a je potřeba k němu přistupovat od jednoduchého ke složitému.

Další věc je, že se zde používá terminologie, která ještě není ustanovená, například jak říkat té „content“ šabloně?

Jan Tvrdík> konstrukce $s = '<!doctype html>' . "\n"; uff, to je nešťastné. Totiž v dokumentaci by se pokud možno nikdy neměli objevovat negativní příklady, když už, tak s upozorněním.

odin

Já bych tedy řekl, že nejlepší je posloupnost: definovat pojmy – uvést užitečný příklad – vysvětlit střeva – popsat další fíčury/uvést další příklady. Jestli si můžu dovolit navrhnout něco jako příklad tak je to následující kousek (jedna z věcí, která mě kdysi přesvědčila, že má smysl se další měsíc trápit s frameworkem, kterému chybí dokumentace).

Aplikace je rozdělena do funkčních celků – modulů, každý modul se stará o nějakou oblast aplikace (správa dokumentů, správa služeb,…) a obsahuje nějaké funkce (výpis, přidání, …). Pomocí šablon nette se dá elegantně udělat to, aby každý modul měl své menu s nabídkou funkcí a svůj obsah stránky.

Obecné rozložení stránky (layout), které obsahuje kompletní kostru každé stránky se odkazuje na „bloky“ #menu, #submenu a #content. Všechny věci, které se v kostře stránky mohou měnit, jsou umístěny v blocích. Soubor app/templates/@layout.phtml:

<?php
<!DOCTYPE html
...
	<div id='main-container'>
		<div id='header'>
			<div id='header-navigation'>
				{include #menu}
				{include #submenu}
			</div>
...
		<div class='content-container'>
		{include #content}
		</div>
...
</html>
?>

Základní šablona bloků, která definuje výchozí obsah bloků #menu, #submenu a #content. Tedy, pokud není dále řečeno jinak, tak #content a #submenu je prázdné, a #menu obsahuje hlavní rozcestník mezi moduly aplikace. Soubor app/templates/Default.phtml:

<?php
{extends $layout}

{block #content}
{/block}

{block #menu}
	<ul class='main-menu'>
		<li class='nav-item'>
			<a class='nav' href='{plink :Documents:Default:default}'>Správa dokumentů</a>
			<a class='nav' href='{plink :Services:Default:list}'>Správa služeb</a>
			<a class='nav' href='{plink :Users:Default:default}'>Správa uživatelů</a>
			...
		</li>
	</ul>
{/block}

{block #submenu}
{/block}
?>

Výchozí šablona modulu Documents (správa dokumentů), block #content obsahuje uvítací text s popisem modulu a blok #submenu nyní obsahuje rozcestník modulu jako takového. Blok #menu obsahuje stále hlavní rozcestník mezi moduly (jeho obsah je zděděný od šablony app/templates/Default.phtml). Soubor app/DocumentsModule/templates/Default.default.phtml:

<?php
{extends "../../templates/Default.phtml"}

{block #content}
	<p>Zde je popis modulu Správa dokumnetů</p>
{/block}

{block #submenu}
	<ul class='sub-menu'>
		<li class='nav-item'>
			<a class='nav' href='{plink List:default}'>Seznam dokumentů</a>
			<a class='nav' href='{plink Detail:default}'>Přidání dokumentu</a>
			...
		</li>
	</ul>
{/block}
?>

Šablona výpisu dokumentů v modulu Documents, ve které je nyní řečeno, že #content už není uvítací text, ale nějaká komponenta (pojmenovaná documentsTable). Blok #submenu je zděděný od šablony app/DocumentsModule/templates/Default.default.phtml. Soubor app/DocumentsModule/templates/List.default.phtml:

<?php
{extends "Default.default.phtml"}

{block #content}
		{control documentsTable}
{/block}
?>

Obdobně funguje výchozí šablona modulu Services (Správa služeb), block #content je opět nadefinován jako uvítací obrazovka s popisem modulu a blok #submenu obsahuje rozcestník v rámci modulu. Blok menu je opět zděděný ze Základní šablony bloků (app/templates/Default.phtml) a tedy obsahuje rozcestník mezi moduly. Soubor /app/ServicesModule/templates/Default.default.phtml:

<?php
{extends "../../templates/Default.phtml"}

{block #content}
	<p>popis modulu Správa služeb</p>
{/block}


{block #submenu}
	<ul class='sub-menu'>
		<li class='nav-item'>
			<a class='nav' href='{plink list:default}'>Seznam služeb</a>
			<a class='nav' href='{plink detail:default}'>Zobrazení služby</a>
			...
		</li>
	</ul>
{/block}
?>

Šablona výpisu služeb v modulu Services. Soubor /app/List.default.phtml:

<?php
{extends "Default.default.phtml"}

{block #content}
	{control filterForm}
	{control resultsTable}
{/block}
?>

toz tak to je takovy napad na uzitecny priklad – asi by se to dalo zkratit (5) a 6) tam v zasade vubec nemusi byt)

Editoval odin (22. 1. 2010 21:39)

22

odin napsal(a):

Já bych tedy řekl, že nejlepší je posloupnost: definovat pojmy – uvést užitečný příklad – vysvětlit střeva – popsat další fíčury/uvést další příklady. Jestli si můžu dovolit navrhnout něco jako příklad tak je to následující kousek (jedna z věcí, která mě kdysi přesvědčila, že má smysl se další měsíc trápit s frameworkem, kterému chybí dokumentace).

Souhlas..už se s Nette seznamuju 3. týden a je to zoufalost.
Za sebe navrhuju zastavit vývoj frameworku do dodělání/zaktualizování dokumentace a všechny síly vrhnout tímto směrem.
Osobně mi je Nette velice sympatický, ale zatím místo času, který by mi měl šetřit, mi ho konzumuje na úkor bloudění v dokumentaci-průvodcích a foru.

Opravdu zatím tedy ještě neprožívám nirvanu z proklamované strmé křivky učení. :-)
Je pravda, že s PHP frameworkem a pokročilým OOP nemám ještě zkušenost, takže na některý věci koukám ja tele na nový vrátka.. :-)
Neberte to prosím jako kritiku, či hanobení dosud odvedené práce, protože i současný stav je kus velké práce vedený dobrým směrem a navíc jako třešnička na dortu je skvělá komunita.
Ale pokud se to má nějak masověji rozšířit i mezi tupější kodéry (já například) :-), tak bez řádné dokumentace, a například sekce „How to…?/ FAQ“, „Kde začít s učením…“, „OOP v PHP“ apod., to půjde ztuha. :-(

Rozhodně se to zatím nedá příliš srovnávat s jQuery, který jsem pro bežnou práci dostal do akce za 2–3 týdny.

Doufám, že se situace brzo změní a nově příchozí uživatelé budou nadšeni nejen z Nette, ale i z dokumentace.

Hezký večer všem,
Marek

Jan Tvrdík

Pokud na konci tohoto vlákna bude funkční dokumentace k dědičnosti šablon (či jak chcete nazývat tento koncept), budu spokojen.

David Grudl napsal(a): Je lepší se na začátku vyhnout pojmům dědičnost a přepisování bloků a prostě jen hovořit o blocích a ukázat, co s nimi jde dělat v rámci jednoho souboru.

To je trochu problém, protože bloky jsou v jednom souboru použitelné dost omezeně. Jejich síla je právně v dědičnosti.

Napadají někoho jednoduché, smysluplné a efektivní příklady na využití bloků v jednom souboru?

Ondřej Mirtes

David dobře popisuje problematiku bloků v přednášce z Pardubic, možná by stačilo vzít tu osnovu (včetně obrázků) a převést rozumně jeho mluvené slovo na text.

_Martin_

Jan Tvrdík napsal(a):

Napadají někoho jednoduché, smysluplné a efektivní příklady na využití bloků v jednom souboru?

Na jednu stránku mě napadá: titulek, který je použitý na více místech ve stránce:

...
	<title>{include #title} | Nette Framework</title>
...
	<h1 n:inner-block="title">Dědičnost šablon</h1>
...

Jan Tvrdík

Ondřej Mirtes napsal(a): David dobře popisuje problematiku bloků v přednášce z Pardubic, možná by stačilo vzít tu osnovu (včetně obrázků) a převést rozumně jeho mluvené slovo na text.

Je to moc ukecané. Takový text by nikdo nečetl.

Honza Marek

Sekci OOP v PHP už jsme napsali, jen je potřeba na ní přistoupit přes google.com a ne přes nette.org :-)

22

..jn, ale nenašel jsem nic dobrýho, vetšina dobře npsanejch článku se věnuje akorát základům a tam končí. :-) je hezký vědět co OOP je, ale doozvědět se, kdy používat PRIVATE, PROTECTED, FINAL, kdy inteface atd. tak k tomu jsem nic praktickýho nenašel. Tak jestli by byl nějakej tip?

Ola

David v jednom tvítu psal o http://programujte.com/?…

22

..znám a chápu to jako základ, ale postrádám, k čemu jsou metody třeba Abstract nebo Final v praxi dobré a kdy to např. použít…

edit: jsme tady trochu OT už asi :-)

Editoval 22 (23. 1. 2010 16:11)

Aurielle

Abstract metody tehdy, když se jedná o nějaký základ a budeš tu metodu něčím rozšiřovat (třeba BasePresenter), final tehdy, pokud nechceš, aby se již dále dědila. S interfacy nevím, zatím jsem je moc nepotřeboval… imho to bude pro návrh struktury kterou pak můžou implementující třídy zpracovávat každá odlišně.

Jan Tvrdík

Článek jsem rozšířit a částečně přeformulovat (např. propagace slova layout místo nadřazená šablona).

Osobně jsem si poznamenal následující:

Přidat příklady na práci s bloky v rámci jednoho souboru.
Vysvětlit, co je to vlastně ten „blok“.
Preferovat deklaraci s hashem nebo bez hashe?
‚layout.phtml‘ vs. '@layout.phtml'
Doplnit zmínku o tom, že bloky lze do sebe libovolně zanořovat a dají se volat křížem krážem.
Sjednotlit označení pro {include #foo} – načtení, volání, vložení.
Uvést použití v rámci Nette FW – zmínit automaticky použitý @layout.phtml resp. MyPresenter.@layout.phtml

Má k tomu někdo nějaké další postřehy? Navrhuji brzké přesunutí do oficiální dokumentace, je někdo proti?

Honza Marek

Jan Tvrdík napsal(a):

Preferovat deklaraci s hashem nebo bez hashe?

Bez, je to tak i v příkladech nette (skeleton, CD-collection, …).

‚layout.phtml‘ vs. '@layout.phtml'

To jde i bez zavináče, jo? To jsou mi novinky.

Jan Tvrdík

Nejde. Jde spíš o to, zda to v tom příkladu (který s Nette pojmenovaním šablon vůbec nepočítá) psát se zavináčem (a jak ho tam vysvětlit) nebo to nechat tak jak to tam jde + „Uvést použití v rámci Nette FW – zmínit automaticky použitý @layout.phtml resp. MyPresenter.@layout.phtml“

LM

Honza Marek napsal(a):

Jan Tvrdík napsal(a):

Preferovat deklaraci s hashem nebo bez hashe?

Bez, je to tak i v příkladech nette (skeleton, CD-collection, …).

Nepřijde vám to matoucí že v {block name} píšu bez, a v {include #name} píšu zase s #?

Jan Tvrdík

Osobně preferuji zápis s #, přijde mi hezčí.

Ondřej Brejla

Jan Tvrdík napsal(a):

Osobně preferuji zápis s #, přijde mi hezčí.

Tak tak…jsem na tom stejně.

Honza Marek

Jan Tvrdík napsal(a):

Nejde. Jde spíš o to, zda to v tom příkladu (který s Nette pojmenovaním šablon vůbec nepočítá) psát se zavináčem (a jak ho tam vysvětlit) nebo to nechat tak jak to tam jde + „Uvést použití v rámci Nette FW – zmínit automaticky použitý @layout.phtml resp. MyPresenter.@layout.phtml“

Tak jestli to má být jako příklad, tak určitě ne layout.phtml. Lidi jsou nepozorný a pak je to zmate. Buď teda něco typu mojeKrasnaNadrazenaSablona.phtml anebo rovnou @layout.phtml. Ten zavináč by pak mohlo stačit vysvětlit u „použití v rámci FW“ (že když je tam @layout.phtml, tak to neni potřeba psát).

LuKo

Jan Tvrdík napsal(a):

Článek jsem rozšířit a částečně přeformulovat (např. propagace slova layout místo nadřazená šablona).

Má k tomu někdo nějaké další postřehy? Navrhuji brzké přesunutí do oficiální dokumentace, je někdo proti?

Především díky za přínosný článek. Ke konci jen zmiňuješ víceúrovňový layout. Setkal jsi se někdy s reálným použitím? Možná by přišel vhod i zcela primitivní příkládek.

Jan Tvrdík

LuKo napsal(a): Ke konci jen zmiňuješ víceúrovňový layout. Setkal jsi se někdy s reálným použitím?

Ano, setkal. Dokonce vícekrát. Až mě napadne nějaký jednoduchý (to je ten problém) příklad, dám ho tam.

Jan Tvrdík

Dnes jsem mírně rozšířil úvod a kompletně jsem restrukturalizoval celý článek.

Myslíte si, že je ta změna struktury k lepšímu nebo k horšímu? Co byste na článku zlepšili?