Ideální struktura presenteru

chikeet

Zdravím,

už delší dobu řeším, jak si uspořádat metody v presenteru, aby to dávalo smysl (nejen mně) a dobře se v tom orientovalo. Momentálně používám přístup, kdy mám metody v tom pořadí, jak po sobě jdou v rámci životního cyklu presenteru. Tzn. nejdřív startup, pak actions, handles, beforeRender, renders, pak formuláře a jejich callbacky, továrničky na komponenty a nakonec nějaké helpery. Má to ale pár nevýhod:

pokud jedna metoda/funkce volá jinou, měla by být ta jiná metoda ideálně definována hned po té volající
nejdřív public, pak protected a nakonec private metody
a pravděpodobně ještě nějaká další obecná pravidla, která tento přístup porušuje

Je celkem jasné, že není možné vytvořit strukturu, která by dodržovala všechno výše uvedené. Takže moje otázka zní: Která pravidla upřednostnit a jakou strukturu použít, aby byla pokud možno co nejsrozumitelnější? Jaký přístup používáte vy a jak se osvědčil?

Chci od toho, aby tomu rozuměla většina lidí, kteří s tím budou pracovat. Abych tomu rozměla já sama po dvou letech ve tři ráno po těžkém týdnu. Aby to prostě celkově bylo dobře použitelné.

Pavel Kravčík

Já tam osobně přidávám ještě další aspekt, jak často předpokládám tu danou metodu upravovat a hledat v závislosti na jiných. Takže pokud předpokládám, že se bude často pracovat s 3–4 funkcemi, dám je nahoru.

Využívej pojmenování funkcí v součinnosti s navigátorem IDE:

successArticleForm
successCommentForm
successPeopleForm
callbackArticleForm
callbackCommentForm
errorArticleForm

Všechno okolo dané funkce presenteru můžeš mít pohromadě první createComponent(), pak success() a podobně. A zároveň díky pojmenování v navigatoru budeš mít pěkný seznam všech succesů, errorů a podobně.

David Kudera

Osobně se mi docela líbí tohle pořadí:

private properties pro proměnné v prezenteru (předání dat z action metody do render nebo komponenty)
public persistent properties (public uprostřed, divný že?)
dlouhý komentář se slovem „SERVICES“
private properties pro služby
konstruktor pro předání závislostí (teď mám ale properties pro služby vedle konstruktoru, takže už mi ten public uprostřed nepřijde tak divný)
dlouhý komentář se slovem „COMPONENTS“
protected seznam komponent
dlouhý komentář se slovem „SIGNALS“
dál už pokračují jen action a render metody oddělené opět komentářem s názvem akce

/**
 * @author David Kudera
 */
class ArticlePresenter extends Presenter
{


	/** @var \App\Model\Article */
	private $article;


	/** @var string @persistent */
	public $tab;


	/******************** SERVICES ********************/


	/** @var \App\Model\Articles */
	private $articles;


	/**
	 * @param \App\Model\Articles $articles
	 */
	public function __construct(Articles $articles)
	{
		parent::__construct();

		$this->articles = $articles;
	}


	/******************** COMPONENTS ********************/


	/**
	 * Používám kdyby/autowired
	 *
	 * @param \App\Components\Articles\Detail\IDetailFactory
	 * @return \App\Components\Articles\Detail\Detail
	 */
	protected function createComponentDetail(IDetailFactory $detailFactory)
	{
		return $detailFactory->create($this->article);
	}


	/******************** SIGNALS ********************/


	/**
	 * @param int $id
	 */
	public function handleRemove($id)
	{
		// ...
	}


	/******************** default ********************/


	public function renderDefault()
	{
		$this->template->articles = $this->articles->findAll();
		$this->template->tab = $this->tab;
	}


	/******************** detail ********************/


	/**
	 * @param int $id
	 */
	public function actionDetail($id)
	{
		$this->article = $this->articles->findOneById($id);
		// ... nějaké to ověření
	}


	public function renderDetail()
	{
		$this->template->article = $this->article;		// zbytečné díky komponentě, jen ukázka
	}

}

Žádné další metody už v prezenterech nemám, úplně vše je v komponentách nebo např. modelových třídách. Osobně bych tu reálně neměl ani ten signál, byl by v nějaké browse komponentě.

Editoval David Kudera (18. 3. 2015 20:32)

newPOPE

@chikeet jedna z moznosti je sa s tym mordovať alebo na to kaslat a nechat to na PHPStorm (http://blog.jetbrains.com/…-rearranger/) :)

David Matějka

Nez zacnes premyslet nad tim, jak metody seradit, zamysli se nejdriv, jak se tech metod (a properties) zbavit, respektive nekam presunout.

presunout do sluzeb / utility trid
vytvorit komponenty
osvedcilo se mi do presenteru davat pouze jednu akci (mam tak > 90% presenteru)

Šaman

Jak je vidět, na tohle bude tolik názorů, kolik je programátorů. :)

Já mám nejprve metody pohledů (action, render), pak handlery, pak create components a nakonec pomocné metody, třeba ty, které jsou navázané na nějakou akci těch komponent. Vpodstatě nic jiného v presenterech nemívám.
Akce a rendery stejného pohledu mám u sebe, protože chci mít na jedné obrazovce přehledně zobrazené, co ten pohled dělá a často rozděluji pohled na akci a render jen z akademického důvodu – veškerou přípravu pohledu a nastavení komponent mám v action a pak v render už jen předávám hodnoty do šablony – imho to patří k sobě.

Filip Procházka

My máme vždy akce, render metody, before/after render a pak komponenty… signály a všechna komplexita je schovaná v komponentách nebo ve facades, takže presentery mívají jenom pár řádků.