posielanie parametrov zo sablony do komponenty

xr

mam volanie komponenty v sablone

{control headerImage, $group => 1, $params => array('alt'=>'haf')}

a toto je vystup (Debug::dump()) parametrov $group a $params, v tomto poradi

array(2) {
   "group" => int(1)
   "params" => array(1) {
      "alt" => string(3) "haf"
   }
}
NULL

este uvadzam hlavicku metody render

public function render($group = null, $params = null) {...}

ako mam docielit, aby som mal v group to cisleko a druhy param tam, kde by som ho ocakaval???

despiq

co dumpujes?

xr

najskor $group, potom $params (dostavam NULL).

uz som to obisiel, skor by som sa rad spytal, cy to je ‚feature‘ nette, ze vsetky parametre pre komponentu strci do jedneho pola.

despiq

<?php
public function render($args);
Debug::dump($args);
?>

xr

tekze toto

public function render($group = null, $params = null)

nebude nikdy fungovat, hej?

despiq

ne, ale nevidim v tom problem

xr

ani, ja len som na to narazil a bol som zvedavy.

redhead

To se mi zrovna nějak nezdá, že by to nešlo (je ale fakt, že jsem snad do render komponenty neposílal víc než jeden parametr)

despiq

<?php
\$control->getWidget($widget)->$method($param)
?>

https://api.nette.org/…ros.php.html#741

to teda nevim jak bys toho docilil bez prepsani LatteMacros

redhead

Ok, beru, neměl jsem čas se dívat do zdrojáku, jen nechápu proč by to tak mělo být. Zdá se mi to dost ošklivé – když už takhle fungujou actiony, helpery, atd, tak nevidím důvod proč by render controlů nemohl přijímat parametry stejně (tj. jako jednotlivé parametry a ne pole).

despiq

osobne mi to tak docela vyhovuje, nemusim pak dodrzovat poradi parametru v sablone, me jako tvurci by to asi problemy nedelalo ale nekdo dalsi by mohl udelat chybu

redhead

Hmm, na to něco bude, ale stejně tak musíš dodržovat pořadí parametrů helperů. Podle mě by to mělo být sjednocené (je v tom pak pěknej guláš, když jeden dává pole, druhý parametry – nehledě na to, že když se předá render() metodě jenom jeden parametr, tak se to do pole nedává, na což zase musím myslet v render metodě a obsloužit param i případné pole..)

despiq

to ze by to melo byt sjednocene je urcite pravda, ze se musi myslet na to jestli to je nebo neni pole to je taky fakt, ted je otazkou co je lepsi treba u helperu by to svym zpusobem bylo na obtiz

<?php
{$date|date:format => '%Y'}
?>

je spis za trest na druhou stranu u toho controlu by zas odpadla moznost prohazovani poradi parametru
mozna by byla hezka varianta aby do controlu vzdy pristalo pole, mozna by to nutilo psat do sablony nazvy tech promennych coz by mohlo i zprehlednit kod

redhead

Rozhodně nechci, aby se u helperů specifikovali názvy proměnných, ale když už si někdo musí pamatovat pořadí u helperů, není moc problém si je zapamatovat u controlů. Mě to tedy problém nedělá. Spíš mě hodně překvapilo takové to chování. Když jde prakticky o volání metody s parametry, nevidím důvod proč by se mělo předávat pole. Ovšem za jistých okolností, by to bylo zas na škodu. Je to dost sporné.

Možná by bylo dobré mít obě řešení – tj. pokud je v parametrech výskyt ⇒ tak by se to převedlo na pole, jinak by se to použilo jako normální parametry. Ovšem to už je dost wtf.

Takže nic. :D