Předání statické třídy do šablony

ForestCZE
Člen | 209
+
0
-

Ahoj, lámu si hlavu nad tím, jak předat do šlabony statickou třídu.

Pokud mám objekt:

use Nette\Security\Passwords;

private $passwords;

public function __construct(Passwords $passwords)
{
	$this->passwords = $passwords;
}

Pak si mohu do šablony poslat celou třídu:

public function renderDefault(): void
{
	$this->template->passwords = $this->password;
}

A v šabloně použít například:

{$passwords->hash()...}

To stejné ale nemůžu udělat se statickou třídou nebo se mi to alespoň nedaří…

Mám:

use Nette\Utils\Strings;

public function renderDefault(): void
{
	$this->template->strings = Strings:: // a už mi to nabízí metody a já potřebuju jednu zavolat až v šabloně
}

{$strings->truncate()}

Jak na to?

Editoval ForestCZE (30. 8. 2020 19:13)

Polki
Člen | 553
+
+2
-

presenter:

use Nette\Utils\Strings;

public function renderDefault(): void
{
	$this->template->Strings = Strings::class;
}

šablona:

{$Strings::trim('   haha')}

EDIT 1: Ale stejně bych to tak asi nedělal. Lepší máš do šablony už posílat vše hotové. Od toho taky view je. Měl by jen zobrazovat data. Maximálně by měl umět výstupně filtrovat proměnné.

Editoval Polki (30. 8. 2020 19:30)

ForestCZE
Člen | 209
+
0
-

@Polki Chápu, že to není úplně správně, ale nevím, jak jinak bych to udělal, když potřebuju použít metodu truncate a data pro její argumenty získám až v šabloně.

ForestCZE
Člen | 209
+
0
-

CZechBoY napsal(a):

https://latte.nette.org/cs/filters#…

Tak toto mě vůbec nenapadlo – trapas. Díky :)

Šaman
Člen | 2632
+
+1
-

Použij filtry. Truncate tam dokonce už máš připravené.
Ohledně práce s textem mi připadá v pohodě řešit to v šabloně. Sahat ze šablony třeba do db dobré není, ale upravit článek třeba na náhled, to šablona klidně dělat může.

P.S. Aha, mám to tu hodinu rozepsané na pozadí a už ti to psali. Holt pozdě… :)

Editoval Šaman (30. 8. 2020 22:29)

Kamil Valenta
Člen | 752
+
0
-

Šaman napsal(a):

Sahat ze šablony třeba do db dobré není…

OnDemand selecty, přegenerování invalidované cache, všechny ->ref() a ->related() konstrukce skládají db dotaz až v šabloně a je to v pohodě.

Polki
Člen | 553
+
+1
-

kamil_v napsal(a):
OnDemand selecty, přegenerování invalidované cache, všechny ->ref() a ->related() konstrukce skládají db dotaz až v šabloně a je to v pohodě.

Nemělo by.
OnDemand select určitě netahá z databáze na úrovni šablony pokud jo, není něco dobře.
Invalidace cache, pokud jde o cache která má v sobě uložený kus šablony je v pohodě. To se stará šablona jen sama o sebe.

->ref() a ->related() by si nikdy v šabloně použít neměl a v pohodě to není. Měl by sis tu strukturu ideálně připravit už před předáním do šablony a v šabloně to pouze vykreslit. Jak jsem psal jediné OK věci jsou výstupní filtry.

Lidi to hojně používají, protože je to jednoduché a pohodlné. To ale ještě neznamená, že to je OK. Představ si například, kdy uděláš nějaký malý projekt. Například prezentační web pro pizzerii, která tam chce jen přehled produktů tahaný z databáze a kontakt.

Najednou přijde požadavek, aby přibyla administrace, kde bude moci admin nastavovat nové pizzy a přidělovat jim suroviny/složení/alergeny. Ty samozřejmě budeš mít ->related() v šabloně u vykreslení pizzy, jelikož každá pizza má více surovin a každá surovina má více alergenů. K tomu přibude vyhledávání podle alergenu, suroviny.

Potom přibude možnost registrace zákazníka, online objednávky a platby kartou s vystavením účtenky.

Toto je v pohodě ale najednou se stane to, že se založí víc poboček a každá bude mít vlastní web a každý zaměstnanec dostane tablet a na něm poběží aplikace, která bude napojena na EET, ale na pozadí musí komunikovat s tebou vytvořeným webem, protože zákazník chce mít jednu logiku na serveru, ale najednou potřebuje jednu aplikaci jako webovou pro zákazníky, jednu mobilní pro zaměstnance, a přijde ještě jedna mobilní pro klienty, kteří si chtějí v mobilu prohlédnout nabídku.

Takže zaměstnanci a zákazníci najednou kromě prohlížeče se připojují ještě přes nějaké API, které ty musíš udělat. OK takže uděláš API, které vlastně vrací ta samá data, která zobrazuje šablona. A najednou máš aplikaci rozědlenou na 2 ty stejné logiky jenže jednu máš v modelu a posílá se jako response na api požadavek a druhou, která je udělaná v šabloně. Tedy jsi porušil DRY princip a to jen proto, že jsi použil ->related() v šabloně a máš špatně navržený kód.

Následující úpravy ve view budeš dělat na 2 místech a to ještě budeš rád, že jich není víc, jako kdyby se například zákazník rozhodl dělat objednávky přes DameJidlo, Wolt, BoltFood apod. Každá tato společnost má nějaké API a každé toto API vypadá jinak. Dobře tak najednou je tam ta logika 5×.

Lepší je udělat si nějakou vrstvu, která ti ta data připraví a do jaké šablony (DameJidlo, Wolt, BoltFood, zamestnanecMobil/zakaznikMobil, webApp) se to vykresle už se nestaráš.

Pokud stále nevěříš, tak nejtypičtější případ je ten, že se zákazník rozhodne, že bude k web appce ještě mobilní. Jelikož ale nechce aby se dělal jeden kousek kódu 2×, tak se rozhodne použít například REACT native, aby měl jednu aplikaci jako klientské rozhraní na všech zařízeních. V ten moment ty musíš zahodit celé latte a z aplikace udělat čistě serverovou část komunikující přes API. Jenže tím, že jsi použil konstrukce, které si získávají potřebná data až v šabloně, tak místo jednoduchého switchnutí odeslání dat místo do lattečka tak pomocí ->sendResponse() ti přibyde práce tu logiku s vytahováním dat z databáze předělat z šablon do modelu například.

Kamil Valenta
Člen | 752
+
0
-

Souhlasím.
Ale pak jsou mnohem drobnější aplikace, kde to zase může být enormně výhodné…
https://phpfashion.com/…ak-jej-resit