Formulář jako komponenta – onSuccess nefuguje

1. Ukázku jednoduché formulářové komponenty máš tady
2. Takhle vypadá řešení pomocí automaticky generovaných továrniček. Pokud je nebudeš používat, tak interface (ILogin…) ignoruj a to, co je v traitě (TCreate…) patří do presenteru.
3. Do komponent všechno musíš předat přes konstruktor, jestli chceš aby se to předávalo samo pomocí autowiringu. Případně setterem, ale pak musíš v továrničce tento setter nastavit.

Zax napsal(a):

Dokážu si představit, že někdo chce používat @inject v komponentách. Je to úplně stejný problém jak u presenterů (Base třída a závislosti, konstruktor hell) a naštěstí tu je možnost @inject zapnout (aspoň tedy pro komponenty generované továrničkami). Sám to už pár dní používám a zatím si spokojeně chrochtám :-)

Ano, zapnout to jde. Ale dokud nemá potřebu to zapínat, tak bych ho neučil způsob, který není podporovaný frameworkem. Myslím, že nehledá způsob, jak zapnout injectování ala presenter, ale teprve dělá první pokusy jak Nette vlastně funguje.

A propo dopiš prosímtě k tomu řešení varování, že anotace @inject je prasárna, která porušuje základní pravidlo OOP a to zapouzdření. Osobně doporučuji v abstraktních třídách používat inject metody, které jsou v pohodě. Presenter je z několika důvodů trochu zvláštní, takže použití anotace @inject se tam snese, ale jen když člověk ví, že tak trochu prasí. Rozhodně by si programátor neměl myslet, že je to čisté.

Ok, bral jsem to podle počtu příspěvků. A podle toho „formulář vytvářím v render“. To je pozdě, protože po odeslání neexistuje formulář, který by přijal výsledky.. ten se vytvoří až při vykreslování.

Editoval Šaman (1. 6. 2014 22:37)

Mimochodem, off topic, tím, že do komponenty vkládáš model přicházíš o znovupoužitelnost, nepletu-li se…? Není to škoda?

Představme si klasickou situaci: Máme blog s články. Máme komponentu, která má na starosti vykreslení článku. A teď jde o to jak ten článek tam dostaneme:

• Můžeme ho předat v templatu, tam ho dostat z presenteru a tam z modelu. Dostaneme tedy text (autora, datum vydání atd.) jako paramatr metody render() komponenty. Ten potom pošleme rovnou do templatu komponenty a je to.
• Můžeme komponentě předat id článku a model a komponenta sama si vytáhne text (atd.) z modelu.

Mě se osobně zamlouvá více druhá varianta protože asi nebudeme vykreslovat článek, který není v db a kód tak rozdělíme do více míst (tj. nebude obrovský presenter). ⇒ Bude to přehlednější.

Možná se ptáte na znovupoužitelnost. Když se kouknete na phpFasion.com, tak uvidíte, že články se vykreslují jak za sebou na homepage tak na stránce článku

moznost 1, tedy predani do renderu v sablone, neni idealni – v komponente pak nebudou korektne fungovat snippety.

Ja pouzivam moznost 3 – do komponent temer vzdy predavam konkretni entitu, kterou si vytvorim v presenteru (respektive na urovni, kde vytvarim onu komponentu)

komponenta se vytvori ve chvíli, kdy ji poprvé zavoláš. Takže můžeš udělat něco jako

/** @var ArticlesComponent @inject */
private $articlesComponent;

public function createComponentArticles()
{
	return $this->articlesComponent;
}


public function actionDetail($id)
{
	$article = $this->articleRepository->getById($id);
	$this['articles']->setArticle($article);
}

Oli napsal(a):

komponenta se vytvori ve chvíli, kdy ji poprvé zavoláš. Takže můžeš udělat něco jako

/** @var ArticlesComponent @inject */
private $articlesComponent;

public function createComponentArticles()
{
	return $this->articlesComponent;
}


public function actionDetail($id)
{
	$article = $this->articleRepository->getById($id);
	$this['articles']->setArticle($article);
}

Tohle he možná nejhezčí, ale já bych předával jenom id a data tahal až v komponentě… (argumenty dříve).

A nelíbí (=myslím že by se mohlo udělat lépe) se mi ta jednořádková metoda createComponentArticles a ta property (Neměla by být public?)…
Jsou tam potřeba? (I v tom tvém řešení) Nefungovalo by to stejně bez nich? … (po chvílí) … Vlastně já si přepisuju petodu createComponent tak, že se to dělá samo :D (viz dříve)

cactux napsal(a):

Tohle he možná nejhezčí, ale já bych předával jenom id a data tahal až v komponentě… (argumenty dříve).

A nelíbí (=myslím že by se mohlo udělat lépe) se mi ta jednořádková metoda createComponentArticles a ta property (Neměla by být public?)…
Jsou tam potřeba? (I v tom tvém řešení) Nefungovalo by to stejně bez nich? … (po chvílí) … Vlastně já si přepisuju petodu createComponent tak, že se to dělá samo :D (viz dříve)

Máš pravdu v podstatě ve všem. Jen jsem se snažil nastínit řešení. Řešení, které plus/minus používám taky popsal lip (a podrobnějc) @matej

To cos udělal s tou createComponent se tady na fórum vrací pravidelně jako chřipka. Je to anti-pattern. Měl bys každé komponentě kterou budeš v presenteru potřebovat, napsat extra továrnu.

A navíc ty injecty děláš špatně, správně takto

$object = $this->context->createInstance($class);
$this->context->callInjects($object);

A vůbec, správně to tady má jenom matej21, byť možná zbytečně složitě, entitu bych předával raději setterem (má to víc výhod než jenom jednodušší konfiguraci).

Zax napsal(a):

@inject anotace v komponentách má i své výhody a navíc cactux dal přímo jasně najevo, že má zájem o anotace ;-)

Nemá to žádné výhody a přestaň prosím lidem radit prasárny.

Konstruktor hell v komponentách neexistuje a pokud ho tam máš tak to děláš špatně.

Mesiah napsal(a):

Mimochodem, off topic, tím, že do komponenty vkládáš model přicházíš o znovupoužitelnost, nepletu-li se…? Není to škoda?

Pleteš.

Oli napsal(a):

komponenta se vytvori ve chvíli, kdy ji poprvé zavoláš. Takže můžeš udělat něco jako

/** @var ArticlesComponent @inject */
private $articlesComponent;

public function createComponentArticles()
{
	return $this->articlesComponent;
}


public function actionDetail($id)
{
	$article = $this->articleRepository->getById($id);
	$this['articles']->setArticle($article);
}

Tohle je taky brutální prasárna, komponenty nejsou služby!

cactux napsal(a):

Tohle he možná nejhezčí, ale já bych předával jenom id a data tahal až v komponentě… (argumenty dříve).

A co když dostaneš neexistující IDčko? Jak pošleš 403 ze šablony?

A naučte se prosím citovat, opravil jsem vám ty příspěvky, není nutné kopírovat stejný text 10×.

Zax napsal(a):

Chtěl inject, tak proč mu neporadit? Mně se inject líbí, mám to napsané hnedka a funguje to.

Tak si to používej ale neraď to ostatním.

Proč tedy u jednoho je to dokonce doporučovaný způsob injectování závislostí a u druhého prasárna? WTF?

• https://www.youtube.com/watch?…
• https://forum.nette.org/…inych-sluzeb
• https://forum.nette.org/…a-steroidech#…

Base control, který chce továrnu na komponentu pro flash messages. Naprosto validní požadavek. Bez traitů. DRY a KISS. Go! ;-)

abstract class BaseControl extends Nette\Application\UI\Control
{
	// https://github.com/Kdyby/Autowired/blob/master/docs/en/index.md
	use Kdyby\Autowired\AutowireComponentFactories;

	protected function createComponentFlashes(IFlashesControlFactory $factory)
	{
		return $factory->create();
	}
}

class PollControl extends BaseControl
{
	private $polls;

	public function __construct(PollManager $polls)
	{
		parent::__construct();
		$this->polls = $polls;
	}
}

„Bez traitů“ není validní požadavek.

Btw, aby base control měl flashky mi přijde dost divný, všechny tvoje komponenty mají vždy flashky? Moje rozhodně ne. Navíc zobrazovat flashky na deseti místech v aplikaci je úchylnost která mate uživatele, daleko lepší je volat $this->presenter->flashMessage() a mít je všechny na jednom místě vykreslené někde v layoutu.

Teda, proc by neměli být komponenty injectovaný jako služby?

V momentě kdy budeš chtít jednu komponentu dvakrát v tom samém presenteru nebo v jiné komponentě v jeden moment, tak ti to nebude fungovat, protože komponenta může být připojena pouze k jednomu rodiči a jenom jednou. Když ji zkusíš připojit dvakrát tak to vyhodí výjimku.

Proto je potřeba vytvářet nové instance komponent pro každé použití. Ideálně pomocí generovaných továrniček.

Pro BasePresentery máme workaround, proč bych tedy neměl úplně ten samý workaround použít i u komponent a místo toho bych to měl řešit ještě úplně nějak jinak?

Jenže ty se na to díváš špatně a ptáš se špatně. Správná otázka je „a proč je to dovoleno v presenterech?“ né „proč to nemůžu používat i jinde?“. Na to je pak jasná odpověď, protože property injection v PHP je ten nejproblematičtější typ injekce a nejčistější je konstruktor.

Ještě bych i pochopil, kdybys měl jednu inject metodu (nebo klidně i ty properties) v BaseControlu. To je přijatelný workaround pro usnadnění problému.

Stále to ale není argument pro použití @inject v konkrétních komponentách. Tam bys měl striktně dodržovat konstruktor injection.

Nebaví mě opakovat pořád to samé dokola, poslal jsem ti 3 odkazy, tam je vše vysvětlené, pokud to nechápeš nebo odmítáš chápat tak tvoje smůla, já tě za každou cenu přemlouvat nebudu. Sám si to dělej jak chceš, ale nenabádej jiné programátory k prasárnám.

EDIT: Ano, potřebuji flasky u komponent, moje komponenty jsou velmi často AJAXové a chci zobrazit hlášku přímo před očima uživatele, ne ji schovávat někam do hlavičky když má uživatel odscrollováno do půlky.

Pokud máš složitější strukturu stránky pak to asi smysl dává. Stejně ale nedává smysl mít to úplně všude.

A víš, že v jeden ajaxový request můžeš invalidovat zároveň víc než jednu komponentu? Není problém invalidovat komponentu a zároveň i flashky v presenteru ;)

Oli napsal(a):

Často ta moje komponenta jen obalovala formulář abych měl čistej presenter. Takovej formulář jsem věděl, že bude na stránce vždy max 1×. Za takového předpokladu to pořád považuješ za brutální prasárnu? Je tam ještě nějakej zádrhel, kterej nevidím?

Komponenta prostě není služba. Zatím se mi nikdy nevyplatilo napsat méně kódu za cenu ústupku z čistoty. Vždy jsem se na to buď já nebo kolega nachytal protože se to chovalo nestandardně.

Nejlepší co můžeš udělat je, říct si nějaký standard jaký budete v projektu dodržovat a ten mít prostě v celém projektu. Dělat v tomhle případu věci tak a v tomhle jinak, když je to možnost dělat jedním způsobem (bez nějakých návrhových ústupků), je vždycky horší.

Filip Procházka napsal(a):

Jenže ty se na to díváš špatně a ptáš se špatně. Správná otázka je „a proč je to dovoleno v presenterech?“ né „proč to nemůžu používat i jinde?“. Na to je pak jasná odpověď, protože property injection v PHP je ten nejproblematičtější typ injekce a nejčistější je konstruktor.

Ještě bych i pochopil, kdybys měl jednu inject metodu (nebo klidně i ty properties) v BaseControlu. To je přijatelný workaround pro usnadnění problému.

Stále to ale není argument pro použití @inject v konkrétních komponentách. Tam bys měl striktně dodržovat konstruktor injection.

No hurá, už se někam dostáváme! Ono to v konkrétních komponentách skutečně není třeba, ale je právě problém udržet konstruktor v BaseControl čistý a prostě lepší řešení než inject metody či anotace neznám (pokud si nechci přidávat další závislosti do projektu kvůli něčemu tak triviálnímu). A já preferuji anotace čistě kvůli konzistenci – v BasePresenteru @inject, v BaseControlu metoda inject* by mi prostě přišlo takový divný. Každopádně se bez nějakých kompromisů neobejdu. Workaroundy jsou naprosto zjevně nutné, proto nechápu proč na mě tak útočíš.

BTW traity nemají konstruktor, že? Co když chci na flashky místo BaseControl použít Trait? Jak do traitu dostanu závislost? Dost blbě, co? Potřebuji nějakou magii, která mi to tam dostane. Opět se přímo nabízí (@)inject(*).

Pokud máš složitější strukturu stránky pak to asi smysl dává. Stejně ale nedává smysl mít to úplně všude.

A víš že v jeden ajaxový request můžeš invalidovat zároveň víc než jednu komponentu? Není problém invalidovat komponentu a zároveň i flashky v presenteru ;)

Jednoduché stránky se časem mohou přetvořit ve složité. Radši to udělám už od základu jako pro složitou strukturu. Komponenty mám rád a hodlám je používat vždy a všude. Ajax v Nette funguje velmi pěkně, proto ho hodlám používat všude, kde se to hodí.

A ano, vím že se dá invalidovat víc komponent. Mám i některé komponenty, které používají $presenter->flashMessage(), ale třeba pro Ajax inline editaci někde uprostřed stránky to je nevhodné, spíš je lepší zobrazit flashku přesně tam, kde editace proběhla a nevynucovat scrollování na začátek stránky jenom kvůli tomu, abych uživateli oznámil, že právě provedl úpravu položky. Nebo když Ajaxově smaže nějakou položku, tak mu zobrazím flashku přímo na místě, kde ta položka byla (třeba rovnou i s tlačítkem „vzít zpět“) A jak říkám, podobných komponent mám celkem dost. Líbí se mi, že to tak může bez problémů fungovat, připadá mi to user-friendly, Ajax je sexy…

Editoval Zax (3. 6. 2014 20:29)

@Filip Procházka: No popravdě to byla moje chyba, nespecifikoval jsem to a s hanbou přiznávám, že píšu @inject i v konkrétních komponentách, ale činím tak jen ve svých projektech – šetří mi to čas a když není zapouzdřený BaseControl, tak je automaticky porušená zapouzdřenost i v potomcích, takže je to ve výsledku skoro jedno a můžu si klidně ušetřit psaní konstruktoru.

V těch, u kterých hrozí, že kód někdo převezme, používám konstruktor i v base komponentách (právě protože to chci psát co nejčistěji) a je děsnej opruz s tím pracovat – v polovině případů zapomenu zavolat parent::__construct a místo toho prostě znovu nadefinuju stejné properties a vložím je úplně stejně, jako kdyby v BaseControl vůbec nebyly. Což samozřejmě taky sucks a je v tom bordel. Proto si myslím, že prasárna je tak nějak na místě, pokud to vyřeší jinou prasárnu, a jsem rád, že mi dáváš tak nějak za pravdu v případě BaseControl ;-)

Nicméně zrovna tohle (@inject v komponentách) by mě osobně v převzatém projektu trápilo asi ze všeho nejméně, protože bych hnedka pochopil, která bije. A obecně bych ani do public properties nic nezkoušel zapisovat. Každá nastavitelná vlastnost by vždy měla mít setter (nejlépe vracející $this pro fluent cukřík), nezávisle na viditelnosti. Pokud vlastnost nemá setter, automaticky ji považuji za read-only.

No jo, asi si do podpisu přidám upozornění ať mě nikdo nebere vážně :-D Preferuji totiž účelnost, produktivitu a jednoduchost před akademickou čistotou.

Omlouvám se, jestli jsem se nějak dotkl tvé filozofie.

Filip Procházka napsal(a):
Ještě bych i pochopil, kdybys měl jednu inject metodu (nebo klidně i ty properties) v BaseControlu. To je přijatelný workaround pro usnadnění problému.
…
Nejde o mou filozofii, ale o filozofii frameworku. Nette má určité best-practices, které se snaží své uživatele učit. Jelikož se považuju za evangelizátora Nette, tak je prostě učím i já (mimo jiné taky proto, že jim taky věřím).

Tohle téma se tu poslední dobou opakuje (a tentokrát jsem to nebyl já, kdo ho nadnesl:), takže ještě jednou a snad naposledy apeluji na možnost nějak Nette-way zapnou inject metody i pro komponenty. V tuhle chvíli inject metoda v BaseControl vyžaduje, aby se zapsal přepínač autowired: yes ke každému potomkovi. A jak je vidět, mnoho lidí to obchází. Kdo nechce, ten to používat nebude, ostatní to aspoň nebudou muset hackovat.
Naopak anotaci @inject bych klidně zrušil úplně – kdo o ni má zájem, může použit Kdyby. Z důvodu zpětné kompatibility se asi nezruší, ale rozhodně bych ji ani v presenterech neuváděl jako best-practise (v příkladech a v sandboxu), ale spíš jako syntactic-sugar. Nováčci si jinak zvyknou na nevhodný způsob (který pak vyžadují všude) a kritikům to jen dodává munici.
Jo píšu to sem proto, že na poslední sobotu se nedostanu a jak je i z tohoto vlákna vidět, neškodilo by to ještě jednou probrat v nějaké širší komunitě.

Mě osobně by se to nejvíce líbilo takto:

Zax napsal(a):

A skoro mám pocit, že tenhle problém tu řeším akorát já a pár dalších jedinců – to skoro nikdo komponenty nepoužívá?

Používám je úplně na všechno a zatím jsem s tímhle problém nikdy neměl :)

Nebo třeba něco vyvíjíš a nemáš ještě úplně jasné všechny závislosti, tak použiješ nejdřív anotace

Ty nepoužíváš IDE? Přidat a odebrat závislost je otázka několika stisknutí kláves a s nativním autowire v nette/di je změna závislostí úplná lahoda, protože ani nemusíš sahat na config.

protože jejich nesporná výhoda oproti ostatním řešením je ta, že se velice dobře udržují (přidání nebo odebrání závislosti změní dva řádky na stejném místě, nikoliv 4 řádky na 3 různých místech)

Tohle tvrzení je ekvivalentní tomu, jako bys řekl, že statický přístup je lepší, protože je s tím méně psaní.

Šaman napsal(a):

Tohle téma se tu poslední dobou opakuje (a tentokrát jsem to nebyl já, kdo ho nadnesl:), takže ještě jednou a snad naposledy apeluji na možnost nějak Nette-way zapnou inject metody i pro komponenty.

V momentě kdy tohle bude zaplé by default, tak to lidé prostě budou používat na všechno. Když se bez toho nezvládneš obejít, tak napsat compiler extension, který zapne injecty pro všechny komponenty, je práce na 5 minut a kód na 10 řádků.

Filip Procházka napsal(a):

Zax napsal(a):

A skoro mám pocit, že tenhle problém tu řeším akorát já a pár dalších jedinců – to skoro nikdo komponenty nepoužívá?

Používám je úplně na všechno a zatím jsem s tímhle problém nikdy neměl :)

Nemám páru jak to děláš. Taky používám komponenty na všechno a krom toho, že mi v základu chybí pár fičur (views, metoda forward), mám i potřebu používat Base komponenty i na různé další věci. Zatím to u mě vypadá zhruba takto:

• BaseControl: „views“ (pokud se zavolá signál, hledá se šablona se stejným názvem, pokud neexistuje nebo se signál nevolá, hledá se default.latte), metoda forward, metoda redirectOrForward (abych nemusel dokola psát if($this->isAjax())…), metoda enableAjax (v šabloně na to musím myslet, ale nakonec je fajn mít někde po ruce možnost ajax zapnout/vypnout), obsahuje subkomponentu na flash messages, syntax sugar pro kontrolu oprávnění (anotace @resource Zdroj pro celou komponentu + metoda $this->isAllowed([$resource,]$privilege) + magické $this->canSomething, což se přeloží jako $this->isAllowed(‚Something‘) + secured signálům stačí anotace @privilege)
  • BaseCollectionControl: abstraktní metoda na získání kolekce a přetížitelná metoda na filtrování dat (v základu vrací celou kolekci a nic nefiltruje)
    • BasePaginableCollectionControl: subkomponenta paginator + přetížená metoda pro filtrování dat ⇒ paginator díky tomu funguje v podstatě automaticky
      • BaseEditableCollectionControl: automaticky přijímá signály add, edit a delete, kontroluje oprávnění, obsahuje některé základní abstraktní metody pro práci s entitami, v základu bych chtěl, aby to umělo i vygenerovat přidávací/editační formulář z definice entity, ale k tomu jsem se ještě nedostal – zatím tedy řeším formuláře přes abstraktní metody a musím si je u konkrétních komponent dopsat
        • BaseEditableCollectionFilesControl: obsahuje subkomponentu na správu souborů, abstraktní metody pro ukládání vazeb mezi entitou a soubory

a mohl bych pokračovat…

Závislosti jsou jasné:

• BaseControl závisí na IFlashMessagesFactory
• BasePaginableCollectionControl závisí na IPaginatorFactory
• BaseEditableCollectionFilesControl závisí na IFileManagerFactory

Vztahy taky dávají smysl:

• naprostá většina mých komponent chce kontrolovat oprávnění a zobrazovat vlastní flashMessages
• ne každá kolekce vyžaduje stránkovadlo
• naopak komponenta pro kolekce s možností úprav docela určitě bude vyžadovat i stránkovadlo
• k čemu je upload souborů u kolekcí (třeba článků) je snad dost self-explanatory

Všechny tyto komponenty mají svůj validní use-case:

• chci zobrazit jeden článek: použiju BaseControl, vytáhnu článek, kouknu jestli je public, pokud není, zkontroluju oprávnění (třeba pomocí $this->canEdit).
• chci na hlavní straně zobrazit pět nejnovějších témat na fóru: použiju BaseCollectionControl a napíšu metodu na získávání dat z modelu. Limit nastavím v přetížené metodě pro filtrování (někdy se hodí třeba zjistit počet všech položek před aplikováním filtru, proto to mám takto oddělené). Pokud bych chtěl víc položek se stránkováním, použiju BasePaginableCollectionControl
• chci zobrazit administrační rozhraní pro správu uživatelů: použiju BaseEditableCollectionControl a dopíšu nezbytné abstraktní metody.
• chci zobrazit seznam článků, každý článek může mít k sobě připojené libovolné množství souborů, a administrátorovi chci dát možnost spravovat vše přímo na stránce: použiju BaseEditableCollectionFilesControl, dopíšu pár abstraktních metod a nastavím hlavní adresář a povolené typy souborů.

Celé je to hodně založené na DRY a celkem dobře mi to funguje (tedy pokud nejsem nucen všude používat konstruktor, pak jsem naopak docela v pr.), řeším tím spoustu častých problémů. Pokud to dělám komplet špatně, rád se přiučím.

>

Nebo třeba něco vyvíjíš a nemáš ještě úplně jasné všechny závislosti, tak použiješ nejdřív anotace

Ty nepoužíváš IDE? Přidat a odebrat závislost je otázka několika stisknutí kláves a s nativním autowire v nette/di je změna závislostí úplná lahoda, protože ani nemusíš sahat na config.

Že většina IDE umí vygenerovat settery je samozřejmé. Ukaž mi ale IDE, které vezme inject metodu, rozparsuje ji na jednotlivé kousíčky (závislosti) a dá ti možnost stisknutím několika kláves odebrat nějakou závislost. V NetBeans jsem tuto funkci nenašel :-P Vlastnost s anotací smáznu hádej za jak dlouho.

protože jejich nesporná výhoda oproti ostatním řešením je ta, že se velice dobře udržují (přidání nebo odebrání závislosti změní dva řádky na stejném místě, nikoliv 4 řádky na 3 různých místech)

Tohle tvrzení je ekvivalentní tomu, jako bys řekl, že statický přístup je lepší, protože je s tím méně psaní.

Prdlajs. Smazat dva řádky (property a anotace) na jednom místě zabere cca dvě vteřiny i s hledáním, kde přesně mám mazat. Smazat tyto dva stejné řádky a k tomu ještě další dva řádky někde v inject metodě (jeden argument a jedno přiřazení) prostě trvá dýl, říkej si co chceš. Srovnání se statickým přístupem je úplně totálně mimo – statickou třídu do normální třídy budu přepisovat dost blbě, bude to trvat, hodně se přitom sblížím s Tracy a neusnadní mi to vůbec nic, oproti tomu transformace @inject ⇒ metoda inject zabere skutečně jen okamžik a na chodu aplikace se nezmění absolutně nic. A tou anotací si aspoň usnadním bouřlivý vývoj, kdy zběsile přidávám a odebírám závislosti a fakt nechci zrovna řešit, jestli je to čisté, to se dá snadno vyřešit ve chvíli, kdy mám jasně dané všechny závislosti.

Nicméně musím diskutujícím poděkovat (hlavně Filipu Procházkovi), jsou to celkem rady nad zlato!

Editoval Zax (4. 6. 2014 9:16)

Casper napsal(a):

Můžeš prosím upřesnit ty výhody setteru?

Nette když se například kanonizuje, tak musí nejprve posbírat parametry z presenteru (a komponent), tedy jsem schopnej poskládat url, která například předává parametr tvé komponentě a tedy ji tím zinicializuji a když máš blbě ošetřenej životní cyklus v presenteru, tak místo 404 (protože například chci nějaký článek který neexistuje) ti vygeneruju 500.

Je tedy podle mě lepší používat setter a v vždy se v komponentě spoléhat na to, že ta entita tam nemusí být. Sice můžeš dát i = NULL do konstruktoru, aby neumřel když tam nepředáš objekt, ale tady dává setter lepší smysl, protože settery jsou na závislosti bez kterých objekt může existovat.

Nehledě na to, že konfigurace se smrskne z tohohle

services:
    -
        class: SomeArticleControl
        implement: ISomeArticleControlFactory
        parameters: [Article $article]
        arguments: [%article%]

na tohle

services:
    - ISomeArticleControlFactory

(Už aby se dořešilo tohle https://github.com/nette/di/pull/4 :)

Použití se pak změní z

protected function createComponentArticle(ISomeArticleControlFactory $factory)
{
	return $factory->create($this->article);
}

na

protected function createComponentArticle(ISomeArticleControlFactory $factory)
{
	return $factory->create()->setArticle($this->article);
}

Což IMHO není taková hrůza :)

Vždyť to tak je, všude se doporučuje používat konstruktor injection, ale v presenterech si to můžeš ulehčit pomocí @inject nebo inject*(). I v quickstartu je dokonce v presenterech konstruktor injection :)

Nette ti v ničem nebrání, jenom tě v některých věcech zkrátka nebude by default podporovat.

Nemá smysl tady tady dál spamovat vyřešené téma, založ RFC a můžeme se pobavit nad ním.