Bug – revize 374 z SVN – Template::registerFilter()

jasir

<?php
        /**
         * Registers callback as template compile-time filter.
         * @param  callback
         * @return void
         */
        public function registerFilter($callback)
        {
                /**/fixCallback($callback);/**/
                if (!is_callable($filter)) {
                        $able = is_callable($filter, TRUE, $textual);
                        throw new /*\*/InvalidArgumentException("Filter '$textual' is not " . ($able ? 'callable.' : 'valid PHP callback.'));
                }
                if (in_array($callback, $this->filters, TRUE)) {
                        is_callable($callback, TRUE, $textual);
                        throw new /*\*/InvalidStateException("Filter '$textual' was registered twice.");
                }
                $this->filters[] = $callback;
        }
?>

Editoval jasir (26. 6. 2009 10:03)

David Grudl

jj, už je to opravené

jasir

Prima, dik… Ehm… a co že je to macro {widget} ? :) Voní hezky… ;-)

Editoval jasir (26. 6. 2009 10:58)

David Grudl

Původní konstrukce jako

{!$form}

{? $grid->renderGrid()}
{? $grid->renderPaginator()}

{? $list->render(array('selected' => $val, 'height' => 2))}

lze nahradit za

{control form}

{control grid:grid}
{control grid:paginator}

{control list selected => $val, height => 2}

Ani pak není potřeba prvky vkládat do šablony.

Váhám jen, jestli použít skutečně {control …} nebo {control …}

jasir

Díky za reakci, moc pěkné, prohlížel jsem si příklady a je to super. K control vs widget – pokud se z widgetu v průběhu vývoje nemá stát něco jiného než control, pak bych byl pro control, takhle se jen zanese do frameworku nový duplicitní pojem, který přispěje jen ke zmatení začátečníků.

Editoval jasir (26. 6. 2009 20:49)

PetrP

Taky jsem pro použití control, ale proč se neuvažuje i o component? sice není vykreslitelná, ale je divně že by control volal getComponent (o widget ani nemluvě).

Už tak to pro někoho méně zběhlého v nette má obrovský wtf faktor, když někde zavolám {control login} že má hledat componentu login v createComponent případně ještě v createLogin.

jasir

PetrP napsal(a):

Taky jsem pro použití control, ale proč se neuvažuje i o component? sice není vykreslitelná, ale je divně že by control volal getComponent (o widget ani nemluvě).

Do Control přibyla metoda getWidget(). Stejně se dá pojmenovat i getControl().

Už tak to pro někoho méně zběhlého v nette má obrovský wtf faktor, když někde zavolám {control login} že má hledat componentu login v createComponent případně ještě v createLogin.

No, kdyby se prosadila ta supertovárnička, při volání {control Login} by jsi hledal
jen createLogin() (třeba pomocí $control->getControl($name)), tak wtf faktor docela mizí…

Editoval jasir (26. 6. 2009 20:17)

PetrP

Aha getWidget jsem přehlídl. Jen taková otázka neměl by kontrolovat jestli vrací Control a ne jakoukoli IComponent? (to ale asi jen kdyby to bylo getControl, bůh ví co tím widgetem david myslí, zítra to z něho dostanem ;])

Jinak je fajn že jsi davide přidal registraci CurlyBracketsFilter do defaultu, ale chybí mi tam unregisterFilter a unregisterHelper sice toho můžu dosáhnout přepsáním templatePrepareFilters nebo createTemplate ale to mi nepřijde jednoznačné na první pohled.

Taky konečně přestala bejt CurlyBracketsFilter:$macros statická.

Jak to ale vypadá s těma novejma slibovanejma šablonama, to nám je zítra předvedeš jako novinku? Nebylo by lepší kdyby jsme měli možnost se na ně podívat dopředu?

kravčo

PetrP napsal(a):

Taky jsem pro použití control, ale proč se neuvažuje i o component? sice není vykreslitelná, ale je divně že by control volal getComponent (o widget ani nemluvě).

Podľa mňa sa o názve „component“ neuvažuje aj preto, že sme v kontexte šablóny, kde nás zrejme zaujímajú komponenty, ktoré sa vykresľujú (teda controly). To, že {control name} bude volať getComponent('name') mi príde úplne normálne, je to všeobecná metóda, ktorá funguje i na formulároch, prezenteroch, atď… a predtým, ako bolo makro {control ...} dostupné, bolo všetky tieto controly treba nahadzovať do šablóny ručne – napríklad pomocou továrničky a getComponent().

Mám pocit, že problémom je najmä pomenovanie „control“, ktoré sa podobá s „component“, „controller“ a ďalšími a v spojení s terminológiou iných frameworkov robí neplechu. Keby sa volal „widget“, tieto problémy by odpadli, otázkou je, či je to trefné pomenovanie a či by ono nespôsobilo rad iných problémov…

btw. $template->component je deprecated už dosť dlho, nie?

romansklenar

David Grudl napsal(a):

Původní konstrukce jako
{? $list->render(array('selected' => $val, 'height' => 2))}
lze nahradit za
{control list selected => $val, height => 2}

Jde nějak zajistit, aby se parametry widgetu neposílaly v poli?

{control list:edit($id)}

// vygeneruje toto a zkončí parse errorem
$control->getWidget("list")->renderEdit($id)()

{control list:edit $id}

// bez závorek zase parametr obaluje polem
$control->getWidget("list")->renderEdit(array($id))

David Grudl

Že by se třeba detekovalo, jestli macro obsahuje => a podle toho se rozhodlo, zda zvolit pol?

romansklenar

Pokud by to šlo :)

David Grudl

Je to tam.