Best practices – fragment nebo komponenta, helper nebo metoda nebo…?

Kcko
Člen | 465
+
0
-

Ahoj,

rád bych se zeptal, jaké postupy používáte v konkrétnějších situacích, abych případně vylepšil best practies.

A) Mám několik podobných komponent (zdroj dat je jiný, zpravidla jiný dotaz do DB), vykreslují ale to samé, pro zjednodušení třeba nějakou kartu.

Komponenty

CardsByUser
CardsByPopular
CardsByNewest

1) V šabloně komponenty iteruji nad daty a pak, abych měl onu „kartu“ spraoval na jednom místě, tak includnu fragment, který je pak tedy sdílený pro všechny výpisy.

<?php
	{foreach $cards as $card}
		{include 'somePath/fragments/CARD-TEMPLATE.latte', card: $card, someOtherParams: $x}
	{/foreach}
?>

2) Dalším způsobem viz (https://jecas.cz/…e-komponenty) může být vkládat onen fragment jako komponentu.

<?php
	{foreach $cards as $card}
		{control card $card, $x}
	{/foreach}
?>

Co bude lepší používat – 1 nebo 2, výhody vs nevýhody, používate to nějak jinak, jiný způsob?


B) Pokud potřebuji v konkrétní komponentě v šabloně provádět nějaké úkony, mám možnost:

  1. Vytvořit si filter, klidně jen pro danou komponentu a přímo v ní (netřeba ukázky)
  2. Mít public metodu v komponentě a pak používat v šabloně něco jako
<?php
 $control->myHelper($data)
?>
  1. Místo public metody si udělat funkci do šablony, tj.
<?php
	$this->template->myHelper = function($data) {}
?>

a pak používat

<?php
	$myHelper($data)
?>

Opět stejná otázka jako u bodu A).

Editoval Kcko (22. 3. 2023 11:09)

Pavel Kravčík
Člen | 1183
+
0
-

Pokud je komponenta stejná a mění se jen ten zdroj dat, tak na to používám občas „vnitřní stav“ té komponenty. A ona si doplní, co potřebuje a „card“ mívám v komponentně přes multiplier.

class CardList
{
	pf __constructor(private string $type)
	{
	}

	pf createComponentCard()
	{
		return new Multiplier(function () {...
	}


	pf beforeRender()
	{
		$this->template->data = $database->where('type', $this->type)->order($this-> === 'byUser' ? 'user_ranking' : 'views');
	}

	pf handleChangeStatus(int $id): void
	{
	}
}

//latte komponenty
{foreach $data as $row}
	{control card-$row->id}
	<a n:href=changeStatus id: $row->id>chycená karta pokémona</a>
{/foreach}

//presenter
pf createComponentCardByUser()
{
	return $this->CardListFactory->create('byUser');
}
Kcko
Člen | 465
+
0
-

Pavel Kravčík napsal(a):

Pokud je komponenta stejná a mění se jen ten zdroj dat, tak na to používám občas „vnitřní stav“ té komponenty. A ona si doplní, co potřebuje a „card“ mívám v komponentně přes multiplier.

class CardList
{
	pf __constructor(private string $type)
	{
	}

	pf createComponentCard()
	{
		return new Multiplier(function () {...
	}


	pf beforeRender()
	{
		$this->template->data = $database->where('type', $this->type)->order($this-> === 'byUser' ? 'user_ranking' : 'views');
	}

	pf handleChangeStatus(int $id): void
	{
	}
}

//latte komponenty
{foreach $data as $row}
	{control card-$row->id}
	<a n:href=changeStatus id: $row->id>chycená karta pokémona</a>
{/foreach}

//presenter
pf createComponentCardByUser()
{
	return $this->CardListFactory->create('byUser');
}

Ahoj,

multiplier v případě potřeby používám taky i to co jsi načrtl a já to nezmínil.
Jsou i komponenty, které vypisují právě 1 věc, tak pořád používám ten fragment, je to nejmíň práce a je to přehledné.
Nějak jsem narazil prave na jecas.cz a přemýšlel jsem, v čem by mi ta komponenta, která dostane parametry přímo do renderu a slouží vyloženě jako renderovací věc, pomohla.

k B? nic ;)

Gappa
Nette Blogger | 199
+
+1
-

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

Gappa
Nette Blogger | 199
+
0
-

Ještě k B – občas 1, občas 2, zatím nikdy 3 :)

Nejsprávnější bude asi 1?

Pavel Kravčík
Člen | 1183
+
0
-

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Kcko
Člen | 465
+
0
-

Gappa napsal(a):

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

Ahoj,
rozumím, někdy to tak dělám. Nicméně, chci aby se komponenta stara o svoje záležitosti sama, takže předat ji takhle data u mě v mnoha případech není vhodné.

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

S bodem 2 ano, pokud to dává smysl (třeba přidat do oblíbených, to jsem zrovna psal, tak tam taky použiji Multiplier).

Kcko
Člen | 465
+
0
-

Gappa napsal(a):

Ještě k B – občas 1, občas 2, zatím nikdy 3 :)

Nejsprávnější bude asi 1?

:-) jasný, jen jsem chtěl vědět, jestli jsem něco neopomněl.

Kcko
Člen | 465
+
0
-

Pavel Kravčík napsal(a):

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Jak to, že ne? Ty připravíš všechna data rovnou v modelu? Vždyť to je už na úrovni šablony a výpisu řádků a jednotlivých sloupců / hodnot (= na tohle se to většinou aplikuje), to by sis z modelu do šablony musel ty data takhle už připravit (nějaké pole objektů, pole polí …) nebo to máš jinak?

Nenapadá mě jak dědičností šablony aplikovat něco jako

<?php
// vypis v komponente
{foreach $rows as $row}
 {$control->formatColumn($row->heading)} {* tady bude lepší asi helper, ale někdy se k tomu uchylím, protože ta metoda může dělat víc věcí najednou a většinou je to jednorázové pro danou komponentu *}
{/foreach}
?>
Marek Znojil
Člen | 78
+
0
-

Kcko napsal(a):

Gappa napsal(a):

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

Ahoj,
rozumím, někdy to tak dělám. Nicméně, chci aby se komponenta stara o svoje záležitosti sama, takže předat ji takhle data u mě v mnoha případech není vhodné.

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

S bodem 2 ano, pokud to dává smysl (třeba přidat do oblíbených, to jsem zrovna psal, tak tam taky použiji Multiplier).

Ahoj,

pokud chápu správně, tak svým způsobem se jedná principově o datagrid? V tom případě by se mohlo jít cestou, že by jsi vždy definoval callback pro zdroj dat.

Něco jako:
https://nextras.org/…docs/master/#…

Kcko
Člen | 465
+
0
-

Marek Znojil napsal(a):

Kcko napsal(a):

Gappa napsal(a):

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

Ahoj,
rozumím, někdy to tak dělám. Nicméně, chci aby se komponenta stara o svoje záležitosti sama, takže předat ji takhle data u mě v mnoha případech není vhodné.

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

S bodem 2 ano, pokud to dává smysl (třeba přidat do oblíbených, to jsem zrovna psal, tak tam taky použiji Multiplier).

Ahoj,

pokud chápu správně, tak svým způsobem se jedná principově o datagrid? V tom případě by se mohlo jít cestou, že by jsi vždy definoval callback pro zdroj dat.

Něco jako:
https://nextras.org/…docs/master/#…

Ahoj, ano i ne.

Spíše mi jde o renderování, kdy X různých či podobných komponent s rozdílnými zdroji dat ve finále vykreslují to samé a proto jsem vznesl dotaz jak udržovat ono totožné vykreslení, v čem?

Já často používám include latte souboru a přes parametr předám data, pak jsem někde vidět i komponentu, které se data předají do renderu, což se mi moc nelíbí, obojí sem popsal a ukázal nahoře. Jedná se o A) dotaz

  1. už je jen jak řešit defakto formátovací věci v komponentně, protože způsobů je víc (filtry / veřejné metody / funkce které jsou nastavené přímo do šablony atd).
Pavel Kravčík
Člen | 1183
+
0
-

Kcko napsal(a):

Pavel Kravčík napsal(a):

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Jak to, že ne? Ty připravíš všechna data rovnou v modelu? Vždyť to je už na úrovni šablony a výpisu řádků a jednotlivých sloupců / hodnot (= na tohle se to většinou aplikuje), to by sis z modelu do šablony musel ty data takhle už připravit (nějaké pole objektů, pole polí …) nebo to máš jinak?

Nenapadá mě jak dědičností šablony aplikovat něco jako

<?php
// vypis v komponente
{foreach $rows as $row}
 {$control->formatColumn($row->heading)} {* tady bude lepší asi helper, ale někdy se k tomu uchylím, protože ta metoda může dělat víc věcí najednou a většinou je to jednorázové pro danou komponentu *}
{/foreach}
?>

To bych asi řešil další komponentou nebo filtrem, ale asi jsem jen nikdy nepoužil nějaké složitější řešení. Na většinu výpisů v šabloně stačí dobře připravený pohled. Možná si jen nedokážu představit, co ta funkce reálně dělá.

Kcko
Člen | 465
+
0
-

Pavel Kravčík napsal(a):

Kcko napsal(a):

Pavel Kravčík napsal(a):

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Jak to, že ne? Ty připravíš všechna data rovnou v modelu? Vždyť to je už na úrovni šablony a výpisu řádků a jednotlivých sloupců / hodnot (= na tohle se to většinou aplikuje), to by sis z modelu do šablony musel ty data takhle už připravit (nějaké pole objektů, pole polí …) nebo to máš jinak?

Nenapadá mě jak dědičností šablony aplikovat něco jako

<?php
// vypis v komponente
{foreach $rows as $row}
 {$control->formatColumn($row->heading)} {* tady bude lepší asi helper, ale někdy se k tomu uchylím, protože ta metoda může dělat víc věcí najednou a většinou je to jednorázové pro danou komponentu *}
{/foreach}
?>

To bych asi řešil další komponentou nebo filtrem, ale asi jsem jen nikdy nepoužil nějaké složitější řešení. Na většinu výpisů v šabloně stačí dobře připravený pohled. Možná si jen nedokážu představit, co ta funkce reálně dělá.

albae-gallinae-filius :)

Ok můžeme lock.

m.brecher
Generous Backer | 774
+
0
-

@PavelKravčík , @Kcko

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil.

Nějak jsem narazil prave na jecas.cz a přemýšlel jsem, v čem by mi ta komponenta, která dostane parametry přímo do renderu a slouží vyloženě jako renderovací věc, pomohla.

  1. jsem nějak úplně nepochopil, ale parametry předané vyloženě pro řízení vykreslování používám při vykreslování částí webové stránky v responzivním designu. Zde se komponenta vykreslující tentýž navigační prvek vykresluje dvakrát, ato ve dnou případech a) pomocí css breakpointů se zobrazí vždy jen jedna, b) např. navigační menu vykresluji na začátku a na konci stránky a html se mírně liší.

V obou případech a) i b) vykresluje komponenta stejná data z modelu, ale modifikuje se html/css třídy. Takže rovnou do šablony předávám parametr kterým řídím to vykreslování, presenter tím nezatěžuji a šablona je daleko přehlednější.

Kcko
Člen | 465
+
0
-

m.brecher napsal(a):

@PavelKravčík , @Kcko

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil.

Nějak jsem narazil prave na jecas.cz a přemýšlel jsem, v čem by mi ta komponenta, která dostane parametry přímo do renderu a slouží vyloženě jako renderovací věc, pomohla.

  1. jsem nějak úplně nepochopil, ale parametry předané vyloženě pro řízení vykreslování používám při vykreslování částí webové stránky v responzivním designu. Zde se komponenta vykreslující tentýž navigační prvek vykresluje dvakrát, ato ve dnou případech a) pomocí css breakpointů se zobrazí vždy jen jedna, b) např. navigační menu vykresluji na začátku a na konci stránky a html se mírně liší.

V obou případech a) i b) vykresluje komponenta stejná data z modelu, ale modifikuje se html/css třídy. Takže rovnou do šablony předávám parametr kterým řídím to vykreslování, presenter tím nezatěžuji a šablona je daleko přehlednější.

Zajímavé řešení, nicméně proč 2x? Předpokládám, že rozlišuješ mobilní zařízení a desktop ne? Na to stačí serverová detekce a pak nemusíš mít kontrolku 2×, defakto tu samou.

m.brecher
Generous Backer | 774
+
0
-

@Kcko

Když jsme na mobilu, tak je vhodné mít navigaci úplně tu stejnou na začátku i na konci – protože v okamžiku dorolování na konec potřebuje uživatel nabídku kam dál, ne aby musel někam zdlouhavě rolovat. No a data obou navigací jsou identická, grafika a html je skoro stejné, takže jedna společná šablona, ale drobné rozdíly tam jsou – navigace nahoře je na mobilu zabalená a má tlačítko na rozbalení, navigace dole je naopak rozbalená a to bez možnosti zabalení. Takže tady je ideální rozlišit typ vykreslení až v šabloně.

Jiný případ je boční sloupec, kde mám třeba box s kontaktními údaji a telefonem. Na desktopu je boční sloupec nahoře a tak to chci – aby byl kontakt hned na začátku vidět. Na mobilu se celý boční sloupec hodí dolů, kontaktní box tam třeba může zůstat, ale potřebuji ho i někde nahoře, ale ne úplně nahoře. Tak si kontaktní box vykreslím podruhé do sloupce article a na desktopu je skrytý. Zobrazí se na mobilu. Tady je to úplně stejný případ – jedna šablona, jedna komponenta a mírná modifikace html (css třídy) při dvojím vykreslování.

Responzivitu je ideální řešit css a vůbec do toho netahat server. On totiž klient může mít mobil/tablet naležato a pak ho otočit svisle a když to řešíš na serveru tak jseš v háji. CSS fungují vždy.

Parametrem předaným do vykreslování komponenty můžeš i přepínat jaká šablona komponenty se použije. Velkou výhodou když to předáš v šabloně je to, že je to přehledné. V šabloně řešíš grafický vzhled a když se rozhodneš změnit šablonu komponenty, uděláš to v Latte a presenter tím nezatěžuješ.

Editoval m.brecher (22. 3. 2023 21:39)

Kcko
Člen | 465
+
0
-

Mno, drtivá většina věcí co popisuješ se dá řešit rovnou v CSS bez dvojího vykreslení s pozměným markupem, byť mírně.
Existují složitější techniky ve FlexBoxu / Gridu, kterými jde řešit i nemožné, většinou.

Co mnohdy žádoucí není, je vypisovat stejný obsah 2×, jen kvůli tomu, že trošku jinak vypadá a bránit to otáčením zařízení ;-). Jsou komponenty, které na stránce 2× být nemůžou ať už je důvod obsahový nebo technický (třeba formulář viz stejná ID form prvků apod).

Můžeš mi konkrétně ukázat nějaý tvůj příklad oné kontrolky, kterou modifiuješ přes render parametr vzhled nebo něco jiného?

A asi se shodnem, že taková kontrolka má spousty omezení jako např. nemožnost ji překreslit zevnitř ajaxem, neb o ten parametr, který jsi nastavil zvenčí, přijdeš – to mi třeba vadí nejvíc.

m.brecher
Generous Backer | 774
+
0
-

@Kcko

https://www.kniharstvi-honsnejman.cz/

Navigační menu je nahoře i dole ale chování je mírně modifikované.

@front-layout.latte:


{block 'mainMenuTop'}
	{control 'mainMenu', location: 'top', toggle: true}
{/block}

{block 'mainMenuBottom'}
	{control 'mainMenu', location: 'bottom', toggle: false}
{/block}

@layout.latte

<!DOCTYPE html>

<html n:attr="lang: $lang? 'cs'">

<head>

	<meta charset="utf-8">

	<meta name='viewport' content='width=device-width, initial-scale=1.0'>

	{block 'robots'}{/block}

	<link rel='icon' type='image/png'  sizes='32x32' href='{$basePath}/css/images/favicon-32.png'>

	<link rel='icon' type='image/png'  sizes='192x192' href='{$basePath}/css/images/favicon-192.png'>

	{block 'head'}{/block}

	{block 'headTitle'}{/block}

	{ifset 'description'}<meta name='description' content='{include description|stripHtml}'>{/ifset}

	{block 'analytics'}{/block}

</head>

<body class="body body-image">

{*	{block flashes}{/block}*}

	{block 'siteHeader'}{/block}

	<div class="site-container">

		{block 'mainMenuTop'}{/block}  {* tady je první varianta *}

	<main class="main">

		{block 'aside'}{/block}

		{block 'content'}{/block}

		{block 'asideMobile'}{/block}

	</main>

		{block 'mainMenuBottom'}{/block}    {* tady je druhá varianta *}

	{block 'footer'}{/block}

	</div>

	{block 'scripts'}{/block}

</body>

</html>

control MainMenu.php

class MainMenu extends Control
{
    public function __construct(private MenuModel $menuModel, private string $slug)
    {}

    public function render(string $location, bool $toggle)
    {
        $this->template->menuModel = $this->menuModel;
        $this->template->nodeRows = $this->menuModel->getNodeRows();
        $this->template->buttonItemRows = $this->menuModel->getButtonItemRows();
        $this->template->slug = $this->slug;
        $this->template->location = $location;
        $this->template->toggle = $toggle;
        $this->template->render(__DIR__.'/templates/main-menu.latte');
    }

}

main-menu.latte:

{var
    $menuClasses = $toggle ? ['toggle-menu', 'menu-mobile-view'] : [],
    $containerClass = match($location){
        'top' => 'top-menu-container',
        'bottom' => 'bottom-menu-container'
    },
    $linkClass = match($location){
        'top' => 'scrolldown-button',
        'bottom' => 'scrollup-button'
    }
}
<div n:class="main-menu-container, $containerClass">
        {if $toggle}
            {include toggleButton}
        {/if}
        <nav n:class="'main-menu', ...$menuClasses">
            {foreach $nodeRows as $row}
                {var
                    $item = $menuModel->langRow($row),
                    $fragment = $row->slug_cs === '@homepage' && $menuModel->lang === 'cs' ? '#stay' : '',
                    $selected = $menuModel->slug === $item->slug ? 'selected' : null
                }
                <a n:class="'button', $selected" href="{plink 'Article:article'.$fragment, slug: $item->slug}">{$item->caption}</a>
            {/foreach}

            {foreach $buttonItemRows as $itemRow}
                {var
                    $button = $menuModel->langRow($itemRow->button),
                    $buttonItem = $menuModel->langButtonRow($itemRow),
                    $view = $buttonItem->{$location.'_view'},
                    $renderButton = $view !== 'none',
                    $viewClass = match($view){
                        'default' => '',
                        'desktop' => 'desktop-view',
                        'mobile' => 'mobile-view',
                        default => null,
                    }
                }
                <a n:if="$renderButton" n:class="'button', $linkClass, $viewClass" href="{plink 'Article:article#'.$button->fragment, slug: $slug}">
                    <span class="icon-right">{$button->caption}</span>
                </a>
            {/foreach}
    </nav>
</div>

{define toggleButton}
    <div class='button transition toggle-menu-button'>
        <span class='closed-caption'>Menu</span>
        <span class='opened-caption'>Zavřít menu</span><span class='toggle-icon'></span>
    </div>
{/define}

MenuModel.php

class MenuModel extends LangModel
{
    private Selection $menuList;

    public readonly string $slug;

    public function __construct(private Explorer $database)
    {}

    public function setSlug(string $slug)
    {
        $this->slug = $slug;
    }

    public function getNodeRows(): Selection
    {
        if(isset($this->menuList)){
            return $this->menuList;
        }
        return  $this->menuList?
                $this->menuList = $this->database->table('node')
                    ->where($this->langCol('published'), true)
                    ->order($this->langCol('sort'));
    }

    public function getButtonItemRows(): Selection
    {
        return $this->database->table('button_item')
            ->where('node.'.$this->langCol('slug'), $this->slug)
            ->order('sort');
    }

    public function langButtonRow(ActiveRow $activeRow): LangButtonRow
    {
        $tableName = $activeRow->getTable()->getName();
        $langRow =  $this->langRows[$tableName]?
            $this->langRows[$tableName] = $this->createLangButtonRow($tableName);
        $langRow->loadActiveRow($activeRow);
        return $langRow;
    }

    private function createLangButtonRow(string $tableName): LangButtonRow
    {
        return  new LangButtonRow($this->lang, parent::Columns[$tableName]);
    }


}
m.brecher
Generous Backer | 774
+
0
-

@Kcko

A asi se shodnem, že taková kontrolka má spousty omezení jako např. nemožnost ji překreslit zevnitř ajaxem, neb o ten parametr, který jsi nastavil zvenčí, přijdeš – to mi třeba vadí nejvíc.

Taky to používám na jednoduché čistě vykreslující komponenty jako je třeba box s kontaktními údaji, nebo navigační menu, kde jsou pouze html linky a žádné signály nebo formuláře.

A přemýšlím, proč by při překreslování komponenty $this->redrawControl() se neměl znovu použít parametr předaný do šablony komponenty? Takhle z hlavy to nedokážu odhadnout, ale jak jsem si četl dokumentaci a nějaké pokusy s ajaxem jsem dělal, tak při ajaxovém požadavku se vykoná vždy celý kód šablony ale do prohlížeče se odešle jenom označený snippet. Muselo by se to vyzkoušet, ale dopředu bych to nezatracoval.

Kamil Valenta
Člen | 765
+
0
-

Kcko napsal(a):

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

Můžeš mít komponentu pro takový výpis a k ní jednu latte šablonu. Z té komponenty pak můžeš dědit potomky, kterým přepíšeš jen nějakou metodu pro získání dat, ale render necháš z předka.

Kcko
Člen | 465
+
0
-

m.brecher napsal(a):

@Kcko

A asi se shodnem, že taková kontrolka má spousty omezení jako např. nemožnost ji překreslit zevnitř ajaxem, neb o ten parametr, který jsi nastavil zvenčí, přijdeš – to mi třeba vadí nejvíc.

Taky to používám na jednoduché čistě vykreslující komponenty jako je třeba box s kontaktními údaji, nebo navigační menu, kde jsou pouze html linky a žádné signály nebo formuláře.

A přemýšlím, proč by při překreslování komponenty $this->redrawControl() se neměl znovu použít parametr předaný do šablony komponenty ?? Takhle z hlavy to nedokážu odhadnout, ale jak jsem si četl dokumentaci a nějaké pokusy s ajaxem jsem dělal, tak při ajaxovém požadavku se vykoná vždy celý kód šablony ale do prohlížeče se odešle jenom označený snippet. Muselo by se to vyzkoušet, ale dopředu bych to nezatracoval.

Ahoj, tak si to zkus

<?php

public function render($nejakyTvujParametr = null) {}
{control nejakaTvojeKontrola, 'Rucne predany parametr'}

?>

A pak si tu kontrolku překresli zevnitr, tj. `$this->redrawControl()` a asi se budeš divit, ale to je známá věc, ty to takhle nepoužíváš, já dost často, proto to nemám rád a psal jsem o tom.

Každopádně díky za ten tvůj nástřel, je v tom na mě celkem mess, nemusel jsi mi dát celé svoje workflow ;) ale mrknu se na to.

Kcko
Člen | 465
+
0
-

Kamil Valenta napsal(a):

Kcko napsal(a):

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

Můžeš mít komponentu pro takový výpis a k ní jednu latte šablonu. Z té komponenty pak můžeš dědit potomky, kterým přepíšeš jen nějakou metodu pro získání dat, ale render necháš z předka.

Ahoj, chápu, ale tak dědit od složitější komponenty, plné konfigů atd. abych v poděděné třeba část složitého konfigu přepisoval nebo to takhle dělal jen kvůli sdílenému renderu mi nepřijde zcela dobré.

Nicméně jsem rád, že jsem si tady utvrdil myšlenky a dozvěděl se různé postupy.

Kamil Valenta
Člen | 765
+
0
-

Kcko napsal(a):

Ahoj, chápu, ale tak dědit od složitější komponenty, plné konfigů atd. abych v poděděné třeba část složitého konfigu přepisoval nebo to takhle dělal jen kvůli sdílenému renderu mi nepřijde zcela dobré.

V úvodním dotazu je uvedeno, že se jen mění datasource. Pokud se mění i config, závislosti a kdo ví co ještě, tak bych si udělal komponentu v komponentě. Ta vnitřní dostane připravená data a udělá společný render, ta vnější se bude měnit a data připraví podle svého configu a dalších „střev“…

Kcko
Člen | 465
+
0
-

Kamil Valenta napsal(a):

Kcko napsal(a):

Ahoj, chápu, ale tak dědit od složitější komponenty, plné konfigů atd. abych v poděděné třeba část složitého konfigu přepisoval nebo to takhle dělal jen kvůli sdílenému renderu mi nepřijde zcela dobré.

V úvodním dotazu je uvedeno, že se jen mění datasource. Pokud se mění i config, závislosti a kdo ví co ještě, tak bych si udělal komponentu v komponentě. Ta vnitřní dostane připravená data a udělá společný render, ta vnější se bude měnit a data připraví podle svého configu a dalších „střev“…

Ano, napsal jsem toho hodně, ale taky jsem psal, že řeším hlavně renderování, tj. jednotnou cestu k zobrazení (includovaný fragment, komponenta s parametrem v renderu, pak se k tomu přidala komponenta v komponentně atd ..). A to co ty popisuješ už tu padlo a já se o to nepřu ;-)