Zjednodušení životního cyklu? Podruhé

Se vším souhlas.
Zavádějící – protože renderování probíhá až po ní? :o)

BTW, Davide, nechceš sepsat povídání o nových šablonách, když jsi je z gruntu přepsal? :) Bývala by mi stačila přednáška z PS, ale Tomik ji zveřejní až v srpnu :(

Taky jsem pro.

Souhlasím s obojím afterRender() je zavádějící, prepare metody se dají přesunout do action, případně do startup

+1 (jsem pro)

Překvapilo mě, jaké souznění zaznělo nad tím, že se něco zruší ;)

PetrP napsal(a):

prepare<View> se používá i pro vlastní obsluhu signalů. Případně beforePrepare pro hromadnou obluhu napříč všema pohledama.

Teoreticky ano, spíš mi šlo o to, jestli to tak používáš skutečně. Totiž říkám si, že by se tam mohlo objevit třeba beforeHandle().

Co říkáte na tohle?

David Grudl napsal(a):
Překvapilo mě, jaké souznění zaznělo nad tím, že se něco zruší ;)

Mě taky ;-)

Totiž říkám si, že by se tam mohlo objevit třeba beforeHandle().

Jestli to správně chápu, beforeHandle() by vlastně bylo místo beforePrepare().
Zde by se zřejmě tedy mohla řešit nějaká customizace obsluhy signálů? Zdá se to logické, ale já jsem zatím podobnou funknčnost nepotřeboval.

Editoval jasir (30. 6. 2009 23:10)

Jen mě teď napadá – jde provést redirect v renderXYZ()?
Jedná se mi o situaci, kdy na základě nějaké vnitřní hodnoty rozhodujete, že dané view bude přesměrováno.

Ten afterRender() se mi líbil na volání funkcí, které musí jít až po renderu, ty funkce, které se musejí volat v každém pohledu – například generátor title, keywords, apod. Teď je budu muset volat v každém renderXYZ() na konci.

Editoval Jakub Šulák (1. 7. 2009 7:52)

Jakub Šulák napsal(a):

Jen mě teď napadá – jde provést redirect v renderXYZ()?
Jedná se mi o situaci, kdy na základě nějaké vnitřní hodnoty rozhodujete, že dané view bude přesměrováno.

Ten afterRender() se mi líbil na volání funkcí, které musí jít až po renderu, ty funkce, které se musejí volat v každém pohledu – například generátor title, keywords, apod. Teď je budu muset volat v každém renderXYZ() na konci.

Me se taky hodil afterRender… pokud jsem chtel sablonu odeslat jako snippet tak jsem to zaridil prave v afterRender:

<?php
abstract class ServicePresenter extends BasePresenter
{
	private $targetSnippet = NULL;

	public function getTargetSnippet()
	{
		return $this->targetSnippet ? $this->targetSnippet : FALSE;
	}

	public function renderTemplateToSnippet($name)
	{
		$this->targetSnippet = $name;
	}

	protected function afterRender()
	{
		if ($targetSnippet = $this->getTargetSnippet())
		{
			if (!$this->isAjax()) throw new NBadRequestException("This view responses on ajax request only.");
			$this->template->setFile($this->getTemplateFile());
			$this->payload->snippets[$targetSnippet] = (string) $this->template;
			$this->terminate();
		}

		parent::afterRender();
	}
}
?>

Pak mi stacilo v u potomku zavolat $this->renderTemplateToSnippet($name) a sablona se mi vyrenderovala do snipetu…

Jinak zjednoduseni zivotniho cyklu velice vitam!

Editoval washo (1. 7. 2009 10:01)

Jakub Šulák napsal(a):

Jen mě teď napadá – jde provést redirect v renderXYZ()?
Jedná se mi o situaci, kdy na základě nějaké vnitřní hodnoty rozhodujete, že dané view bude přesměrováno.

Dokud se něco nevypíše na výstup, jde volat redirect.

Ten afterRender() se mi líbil na volání funkcí, které musí jít až po renderu, ty funkce, které se musejí volat v každém pohledu – například generátor title, keywords, apod. Teď je budu muset volat v každém renderXYZ() na konci.

Jj, v podstatě kvůli tomu to vzniklo.

Zjednodušování se mi líbí, sám jsem měl problémy se vyznat v tom, co dát do jaké metody. A že jich bylo požehnaně. Navíc továrničky přinášejí mnohem elegantnější a ucelenější způsob práce s komponentami a bude jen dobře, pokud framework bude tuto cestu podporovat.

sodae napsal(a):

jak píše washo tak přesně tohle opravdu teď potřebuji takže afterRender bych nerušil určitě

A není nějaký jednoduchý způsob jak tuhle metodu nahradit?

David Grudl napsal(a):

Můj návrh zní:

1. zrušit metody beforePrepare() a prepare<View>()
2. zrušit metodu afterRender() (její název je velmi zavádějící)

Co myslíte? Jsou případy, kdy to nejde?

A jaky vlastne by mel byt duvod zruseni? Osobne si myslim, ze bud to nekdo vyuziva a pak to oceni a nebo to nekdo nevyuziva a muze mu to byt skoro jedno, ze se takove metody daji psat ne? Takhle mi prijde, ze clovek muze zasahnout do zpracovavani pozadavku na ruznych mistech podle toho, co potrebuje udelat (a nebudu si tu ted vymyslet konkretni veci, protoze vsichni vime, ze se na to vzdycky prijde primo pri vyvoji) a likvidovat tuhle moznost je skoda ne?

prepare metody souhlas – odstranit.

afterRender bych ponechal a ani nevidím důvod, proč měnit název – chápu, že nedochází k renderování před provedením afterRender(), ale pokud se jmenují metody renderXYZ(), tak pak mě logicky napadá, že afterRender() je naprosto v pořádku. Přejmenování bych viděl jako řešení zbytečné zpětné nekompatibility a neřeší to nic… to můj názor.

jsem taky pro odstraneni

První krok učiněn – beforePrepare a prepare<View> patří minulosti (samozřejmě ve zpětnokompatibilním duchu).

Není to škoda? Pokud jen potřebuju zobrazit šablonu kterou naplním daty z modelu, tak se krásně hodí render, kde mám pouze něco jako

$this->template->foo = $this->model->getBars();

Je docela zbytečné to ládovat jako property presenteru a ještě to anotovat (nebo vytvářet Control o ničem a ten pak widgetovat), takhle mi to přijde přehlednější. Nebo ne?