Latte: jak zapisovat lokální/privátní bloky

Neměla by ta lokálnost být spíš součástí maker define a block? Přijde mi to logické a je to i analogické k definici proměnných a funkcí v PHP, tedy public $foo, private $foo.

Kdybych měl hádat, jak asi bude makro – které bude dělat totéž, ale lokálně – vypadat, hádal bych něco jako {definelocal toc} resp. {blocklocal toc}. Případně {localdefine toc} a {localblock toc}

Pořád to není ono, ale pro mě lepší než přidávat další druh syntaxe, který vnáší zase něco nového do pravidel a tedy je komplikuje.

1. Zatím to možná není špatné, ale pokud se opravdu prosadí pojmenované parametry, mohla by se tahle syntax stát hodně matoucí.
2. Nepřijde mi správné uvádět local u {define ...} (pouze u {include ...}).

Možná by bylo lepší použít dvě dvojtečky.

{include local::toc, $page->toc}

Mohlo by to být zajímavé, pokud bys implementoval i jiné „scopes“, třeba child::someblock nebo parent::block. Pak by se tohle mohlo jmenovat spíš self::toc. Každopádně myslím, že by nemělo být klíčové slovo určující „scope“ v definici, pouze u použítí, kde tím zadáme „cestu“ k definovanému bloku.

Např. pomocí {include child::content} bych vyřešil {include subsubsubcontent}, s čímž často bojuju.

Ale to už je jiná věc, nevím, jestli to chceš vést tímto směrem a jestli v současné implementaci si bloky pamatují „scope“/kontext/šablonu, ve které byly definovány, a může třeba existovat blok se stejným názvem v různých šablonách v hierarchii.

Edit: Vlastně, určení bloku jako „private“ přímo při defnici, je ještě něco jiného, než o čem jsem psal. Tam by se mi zdálo nejlepší {definelocal block}. K takovému bloku by latte nepovolilo přístup odjinud, aspoň při zadání pouze jména bloku.

Teď by se to možná dalo jednoduše vyřešit podtržítkem na začátku názvu bloku.

{define _toc, $items}
{include _toc, $page->toc}

Latte engine by pak pracovalo s takto nazvanými bloky tím novým způsobem. Tahle syntax by aspoň okamžitě měla hatery, lidi, co budou hned vědět, co to dělá, lol.

Editoval filsedla (11. 11. 2020 9:59)

To podtržítko nepovažuji za dobrý nápad. Úplně vidím ty dotazy. „Hele mám tu blok _abc a nejde mi includovat“. Nejvíc se mi asi líbí to {define local abc, ...}

Z toho popisu mi prijde, ze jde o dve ruzne veci a latte by na to melo ruzne reagovat

1. Někdy však v takových šablonách potřebujeme vytvořit blok, který by neměl být k dispozici v jiných šablonách

V tom pripade napr. to local a pokud pouziju v podrizene sablone stejny nazev bez definice, tak bych mel byt upozornen, ze block neexistuje

2. ani by neměl přepisovat další bloky, pokud se jejich náhodou názvy shodují.

Napr. final? Pokud se budu snazit redefinovat block v podrizene sablone, melo by me to upozornit, ze block se stejnym jmenem existuje a menit ho nemuzu

Je to taky možnost. Otázkou je, jestli by pak mělo existovat i makro {includelocal} (což už má zavádějící význam) nebo > > {include foo} by měl přednostně includovat lokální blok?

Možná by se měla vyhodit chyba, pokud se budu snažit vytvořit takový blok lokálně, který už existuje globálně a naopak.

Block foo can't be defined both globally and locally in …

Tyhle věci nechci míchat. Buď vím, že block budu používat i v jiných šablonách a vytvořím ho normálně nebo vím, že ho chci jenom lokálně a nebudu na něj používat již existující název, dělalo by to akorát zmatky. Toto mě přinutí držet kód přehlednější.

Držel bych chování stejné jako dle jiných jazyků, tedy samotnou viditelnost bych nastavoval přímo v tom bloku, tedy varianty:

{define local abc} vlastně odpovídá: private function abc

Mě se víc líbí naopak spíš keyword private a to právě kvůli identitě napříč jinými jazyky – ale jako netrvám na tom ;).

{import abc} by pak obdobně includoval nejdřív private (pokud existuje), pak až public.

Styl podtržítko bych nedělal, příliš mi připomíná hrůzy dob dávno minulých.

Includování pomocí scope, tedy je imho něco navíc, protože:
{include self::abc} je to samé jako {define local abc} {include abc}
{include parent::abc} je to samé jako {define abc} (v parentu) a {include abc}
{include child::abc} by mi dávalo smysl pouze když by šel block definovat jako abstraktní, tedy {define abstract abc}

Jak naznačují ostatní příspěvky, tato diskuze může snadno rozrůst do dalších nastavovávatek viditelnosti, tedy např. final, protected apod. Je otázkou kde je ta lajna kde to prozatím ukončit :).

medhi napsal(a):

Buď vím, že block budu používat i v jiných šablonách a vytvořím ho normálně nebo vím, že ho chci jenom lokálně a nebudu na něj používat již existující název, dělalo by to akorát zmatky.

V tom případě nepotřebuješ lokální bloky. Jejich smysl je právě v tom, že nemusím přemýšlet, jestli náhodou ten název není jinde použitý.

Viz ten úvodní příklad. Vytvořím si pojmenovaný blok kvůli rekurzivnímu vykreslení menu kdesi v sidebaru. A nechci v tu chvíli řešit, jestli náhodou v nějaké jiné šabloně není blok stejného jména a mohlo by to něco pokazit.

David Grudl napsal(a):

xificurk napsal(a):

Docela chápu, že rozlišení pomocí jména bloku se může zdát pohodlné.

Ne, to není pomocí jména. Na jméno to nemá vliv. Je to prostě „nějaké označení“, že tento blok je local/private.

Aha, jak to tedy funguje v kombinaci s dynamicky pojemnovanými bloky?

{var $name = 'local:foo'}
{block $name} ...normální? blok
{block local:$name} ...lokální? blok

A interagují mezi sebou nějak normální a lokální bloky se stejným jménem, jak?

Nebo to jsou dvě úplně oddělené sady s tím, že i v případě include musím vždy explicitně specifikovat jestli chci lokální blok, nebo ne? Nebyla by to tedy potom další známka toho, že by měla existovat oddělená sada maker pro lokální bloky?

xificurk napsal(a):

Aha, jak to tedy funguje v kombinaci s dynamicky pojemnovanými bloky?

Budu používat místo {block local:xxx} syntax {block local xxx} na které tu byla většinová shoda, ale jinak to funguje stejně.

{var $name = 'local foo'}
{block $name} //  vytvoří normální blok s názvem `local foo`
{block local $name} // vytvoří lokální blok s názvem `local foo`

(přesněji řečeno, v tuto chvíli vyhodí {block local $name} výjimku, protože lokální dynamické bloky nejsou podporované, jelikož nevím jestli jsou potřeba)

A interagují mezi sebou nějak normální a lokální bloky se stejným jménem, jak?

Ne.

Nebo to jsou dvě úplně oddělené sady s tím, že i v případě include musím vždy explicitně specifikovat jestli chci lokální blok, nebo ne?

V tuto chvíli se to u include musí specifikovat. Ale jak jsem psal výše, bylo by možné i chování, kdy bere primárně lokální blok a pak by se to nespecifikovalo vůbec.

Nebyla by to tedy potom další známka toho, že by měla existovat oddělená sada maker pro lokální bloky?

Je to čistě věc syntaxe, jestli psát {blockLocal foo}...{/blockLocal} nebo {block local foo}...{/block}.

A co lokální blok obklopit:

{local}
    {define...}
{/local}

Nebo zavést něco jako namespace šablony. Kdybys includoval/volal, udal bys, z jakého namespace. A ty namespace by mohli mít viditelnost, něco co v PHP teď chybí.

Milo napsal(a):

Nebo zavést něco jako namespace šablony. Kdybys includoval/volal, udal bys, z jakého namespace. A ty namespace by mohli mít viditelnost, něco co v PHP teď chybí.

To asi máš na mysli nějaký scope jako tu zmiňoval @filsedla. Do toho se pouštět neplánuju, nemám pro to usecase.

Kori napsal(a):

Z pohledu dedicnosti a tam bych chtel, aby to melo jasne a predvidatelne chovani.

Privátní (resp lokální) prvky z pohledu dědičnosti neexistují.

David Grudl napsal(a):

Kori napsal(a):

Z pohledu dedicnosti a tam bych chtel, aby to melo jasne a predvidatelne chovani.

Privátní (resp lokální) prvky z pohledu dědičnosti neexistují.

Proste si nerozumime, v pohode 🙂

David Grudl napsal(a):
Technicky tomu nic nebrání, ale mám pokušení to nepovolit

Imho nepovolit, pokud někoho nenapadne reálně užitečný use-case. Striktnější pravidla způsobují méně WTF momentů. A dva stejně pojmenované bloky v jedné šabloně znamená mít v hlavě přesný algoritmus kdo má kdy přednost, jinak to ty WTF momenty způsobovat bude.

David Grudl napsal(a):

Přemýšlím nad tím {include} a myslím, že tam se prostě local uvádět nemusí.

• pokud mám v šabloně lokální blok foo, pak {include foo} znamená že chci inkludovat tento lokální blok
• pokud mám v šabloně lokální blok a chci inkludovat nelokální blok foo (tedy vím o tom že existuje), tak přece nebudu dávat lokálnímu bloku název foo a dělat si v tom hokej
• v šabloně by mohl být lokální blok foo a zároveň nelokální (kvůli tomu, že přepisuje blok z jiné šablony). Technicky tomu nic nebrání, ale mám pokušení to nepovolit

Jan bych to zakazal a pouzivalo by se pouze include bez local. Sice to ted nabizi o neco vetsi flexibilitu, ale kdyz nahodou nekdo bude potrebovat prepsat include blok, tak si ten lokalni prejmenuje.