Komponenty a jejich (ne)vykreslení

https://forum.nette.org/…eco-vykresli

Proč ne?

V šabloně presenteru máš presenter dostupný pod $control. Můžeš tak přistoupit ke komponentě presenteru a dotázat se jí, zda je možné ji vyrenderovat

{if $control[articleList]->isRenderable()}
	{control articleList}
{/if}

class ArticleList extends Control
{

	public function isRenderable(): bool
	{
		//TODO - implement
	}

}

Řešení s capture a ifcontent mi osobně nepřijde tak hezké, ale pokud komponenta nevypíše žádný výstup (ani prázdné html elementy), tak bude fungovat též

Editoval Mabar (3. 3. 2021 12:22)

Tak místo toho měj metodu v presenteru? Já přece nevím, za jakých podmínek tvá komponenta něco vykreslí – i při předání dat v konstruktoru může zjistit, že nevypíše nic.

Mabar napsal(a):

Tak místo toho měj metodu v presenteru? Já přece nevím, za jakých podmínek tvá komponenta něco vykreslí – i při předání dat v konstruktoru může zjistit, že nevypíše nic.

Snažím se přijít na obecné řešení, které by bylo jednoduché, efektivní a rychlé. Podmínka nevykreslení je napsaná nahoře v komentáři u HTML.

Nehledám radu, jak to udělat, hledám řešení, jak by to dělali ostatní, abych se měl čím inspirovat.

Metodu v presenteru mít můžu, ideálně ale do šablon moc objektů tahat nechci a předávat něco do šablony znamená pro mě vytvořit i render metodu, protože pouze tam bych chtěl mít data, která se do šablony posílají. A pak už se to dost rozrůstá na takovou situaci, kdy vlastně potřebuju jen jednoduchý if.

Editoval joe (3. 3. 2021 13:17)

Je přeci zcela rozhodující kdo a kdy zjistí, že se nebude nic vykreslovat.
Pokud to zjistí už presenter, jak je uvedeno v prvním příspěvku, tak to mohu rovnou v šabloně odpískat.

{if $presenter->articles}
<div>
  {control articleList}
</div>
{/if}

S tím, že articles musí mít getter, nebo být public (rozdíly nejsou předmětem vlákna).

Nebo si data obstará až komponenta sama, pak viz @Mabar

Nebo se do toho promítne kdo ví co, pak musíš sledovat vyrenderovaný content, zda není prázdný.

IMHO nejrychlejší bude sahat na articles, protože jen tak se vyhneš instancovaní komponenty a prakticky jen zužitkuješ data, která jsi z modelu už vytáhl.

A pokud chceš mít „jednošmahové“ použití tak, aby se to celé mohlo dít opakovaně ve více presenterech, tak to celé ještě zabal do jedné komponenty, která bude brát $articles a rozhodovat, zda se vykreslí <div> a ArticleList nebo ne.

Editoval dakur (3. 3. 2021 15:41)

@Mabar Hm, hm, z tohohle pohledu datagridu máš pravdu, ale ten datagrid chceš pořád vypisovat. Asi je teda potřeba si říct, že tato komponenta bude vždycky něco vracet a jiná komponenta vracet nic nebude. A jak se stavíš k tomu instancovat něco, co není vlastně potřeba? :)

@dakur A píšeš to tak? :) Skoro jsem si říkal, že by se mi celkem hodilo, kdyby továrna vrátila null, ale nevím jestli to není proti nějakému návrhu (?, každopádně teď to nejde). Ta tvá ukázka by se pak mohla jednoduše zkrátit na:

class HomepagePresenter {
  /** @inject */
  public ArticleListFactory $articleListFactory;

  /** @inject */
  public ArticleRepository $articleRepository;

  protected function createComponentArticleList(): ?ArticleList
  {
    $articles = $this->articleRepository->findAll();
    if (\count($articles) === 0) {
        return null;
    }
    $articleList = $this->articleListFactory->create($articles);
  }
}

a v šabloně pak

<div n:if="$presenter->getComponent('articleList') !== null">
  {control articleList}
</div>

Volit další obalovou komponentu se mi pak už moc nelíbí, myslím že by nebyla pak moc znovupoužitelná. (Obalové elementy articleList mohou být různé)

@KamilValenta z šablony bych do presenteru moc nesahal, nejspíš by pak nefungoval ani refaktoring kódu a bylo by to těžce dohledatelné. Ale chápu myšlenku.

@DavidMatějka Ten „obrácený“ if jsem neznal, doufám že ho nikdy nebudu potřebovat :D

@Mabar Jestliže se má komponenta vykreslovat za určitých podmínek zároveň s <div>em, který je mimo ni, pak o tom nemůže rozhodovat komponenta právě proto, že ten <div> jí nepatří. Kdyby byl <div> v ní, pak samozřejmě ano.

@joe Ano, používám. Např. mám komponentu, která vykresluje dlaždici s různými informacemi. Těchto dlaždic mám pak na stránce více a tuto funkcionalitu „seznam dlaždic“ jsem potřeboval ve dvou presenterech – udělal jsem tedy i komponentu pro seznam dlažic, která renderuje X komponent jednotlivých dlaždic.

Ifovat to pomocí pomocné proměnné mi přijde lepší už z důvodu toho, že to máš typované skrz {templateType} (pokud ho používáš) a já osobně jsem zastáncem toho, aby se v šablonách neprogramovalo – což $presenter->getControl('xxx') !== null už trochu je.

Editoval dakur (3. 3. 2021 17:18)

@dakur

Jestliže se má komponenta vykreslovat za určitých podmínek zároveň s <div>em, který je mimo ni, pak o tom nemůže rozhodovat komponenta

Ona ale nerozhoduje o tom, jestli se vykreslí, jen mi říká zda má co vykreslit. O tom zda se vykreslí rozhoduje podmínka okolo toho divu :)

Editoval Mabar (3. 3. 2021 17:18)

@Mabar Ono ale nejde z továrny vrátit null, pak to křičí did not return or create the desired component. Ale bylo by to asi takový nestandartní :)

Ok, tak za podmínky, že při instancování komponenty se nebude nic moc složitýho dít, což bych asi ani neočekával, tak se zdá dobrá ta metoda, jestli jsou nějaká data.

Pak je ale trochu složitější, když by komponenta přijímala víc parametrů a na všechny by se pokládal dotaz. V případě, že by už první nic nevrátil, tak bych to musel ifovat v datech a pak tam posílat prázdná data :D No u takového scénáře zase moc nevím…

Nejspíš jedno ideální řešení nebude.

@Pepiik Je to takový jednoduchý efektivní řešení, jen hodně ukecaný. Zajímalo mě, jak takové situace řeší ostatní.

Ten nápad s jinou šablonou zní zajímavě ;-)