Struktura inject a závislosti presenterů

akvizice je v jazyce DI služba, má tedy své závislosti. Například repositáře.
Do akvizice di všechny závislosti injectuj kongruktorem a akvizici si injectuj do class Cron.
A doporučuji si výstup do emailů přesunout do modwlu, pokud k nim chceš přistupovat z více prezenterů. Potom nebudeš muset volatmetody jiných presenterů, ale injectuješ si modelovou třídu zodpovědnou za posílání emailů.

promiň ty překlepy, psal jsem z mobilu
injekce konstruktorem
ukázka injekce konstruktorem v nette sandboxu

místo

	/** @var Nette\Database\Context */
	private $database;
	public function __construct(Nette\Database\Context $database)
	{
		$this->database = $database;
	}

tam budeš mít

	/** @var NamespaceTvychRepositaru\UkolRepository */
	private $ukolRepository;

	/** @var NamespaceTvychRepositaru\SchuzkaRepository */
	private $schuzkaRepository;

	public function __construct(NamespaceTvychRepositaru\UkolRepository $ukolRepository, NamespaceTvychRepositaru\SchuzkaRepository $schuzkaRepository)
	{
		$this->ukolRepository = $ukolRepository;
		$this->schuzkaRepository = $schuzkaRepository;
	}

a Akvizici zaregistruj do config.neon jako službu injectni si ji do presenteru nějak takhle

/** @inject @var \NamespaceAkvizice\Akvizice */
    public $akvizice;

Ano to jsem zkoušel, ale $ukolRepository v konstruktoru bude přeci prázdný a zahlásí chybu must be an instance of \Namespace\UkolRepository. Protože tohle se řeší v inject() správně. A konstruktoru by to jít nemělo – jestli dobře chápu.

Mám jí jako services registrovanou. Tam problém není. Asi jsem se nepřesně vyjádřil. Hodím struktrukturu. Modul je pro mě složka, kde jsou všechny repository, presentery a templates s spojené s danou jednotkou. Prostě v akvizicích se dělá vše okolo akvizic (správa,výpis,šablony apod.). Tento modul snadno umí připravit HTML výstup z DB těch emailů. Ale posílání bych rád spouštěl něčím jiným, kde nad tím mám kontrolu + log. Od toho byl jiný modul.

Teď mi napadlo to obejít třeba uložením do $session, $db. Ale to neřeší můj dotaz. Jak volat presenter, který by byl naplněný svými závislostmi.

Stejně možná jako kdybych měl Akvizice a chtěl je rozšířit jiným presenterem např. AkviziceDokumenty – ten by dědil od Akvizice (extends) a měl by jiný inject. První má ukolRep,schuzkaRep a druhý by přidal dokumentyRep. V tom případě hodí Nette chybu, že inject není kompatibilní s předkem.

app
	- Akvizice (modul)
		- presenters
			-AkvizicePresenter (tam je metoda actionCronMail)
		- repository
			- ukolRepository
			- schuzkaRepository
	- Cron (modul)
		- presenters
			- CronPresenter
		- repository
			- logRepository

Editoval kzk_cz (4. 12. 2014 15:44)

á, jo takhle jsi to myslel s tou stukturou…já to špatně pochopil…

Doporučuji v presenterech nemít business logiku. Vytvoř si modelovou třídu, kam naházíš business logiku z AkvizicePresenteru a tu modelovou třídu si injectni do AkvizicePresenteru a CronPresenteru.
A když budeš mít akvizici jako modelovou třídu, tak tam injectuj konstruktorem a v CronPresenteru normálně zavoláš metodu té modelové třídy a nebudeš muset řešit, jak z jednoho presenteru volat metody jiného.

Určitě znáš MVC/MVP strukturu.
M-model- business logika aplikace, sem patří repositáře a další věci, které řídí logiku aplikace a „něco dělají“.
V-view, template, šablona.
C/P-presentery- krmí šablonu daty, která získají z modelu a říkají modelu, co má udělat podle aktivit uživatele. Presenter nemá obsahovat business logiku, tu má zařizovat model/služby, které presenter dostane jako závislosti.

Modelová třída je součást modelu z MVC a to je to samé jako service/služba, pokud používám pojmy DI.
Takže si vytvoříš novou třídu (službu), která ti bude zajišťovat business logiku akvizice. Registruješ ji do config.neon jako tam máš repositáře.
Hádám, že akvizice bude mít výše zmíněné repositáře jako závislosti, tedy injectuješ je tam konstruktorem.
A akvizici si injektuješ do akvizicePresenteru přes konstruktor, inject metodu, inject anotaci, tady je to víceméně jedno.
A akvizici si injectuješ i do CronPresenteru.

Hm, s Nette 2.0.5 nemám zkušenosti. Jak tam funguje dependency injection? Jak dostaneš repositáře do presenteru? A jak dostaneš připojení k databázi do repozitářů?

Předávání repositářů ručně je prasárna, od toho máme dependency injection, abychom tohle nemuseli dělat.

Při používání dependency injection by sis zásadně neměl sám vytvářet nové instance presenterů a služeb (tedy používání klíčového slova new), to všechno udělá DI za tebe.

Aha jasně. Fakt díky moc za ten čas, který s tímhle strávíte!

V současné chvíli to funguje, že presenter si zavolá inject(7 repositářů tady) a pak s nimi pracuje. Potřebuju vlastníka,klienta úkolu → tak například takto.

Udělám nějaký magic příklad, jak přibližně s tím pracuju (jak jsem se to naučil).

AkvizicePresenter
inject(ukolyRepository $ukolyRepository, ...)
{
	$this->ukolyRep = $ukolyRepository;
	... //další repository 6x
}

function renderMojeUkoly($idAkvizitora)
{
	$akvizitor = $this->akvizitorRepository->vyhledejDleId($idAkvizitora); //return some selection of row
	$klienti = $this->klientRepository->vyhledejMoje($akvizitor->id);
	$schuzky ... //podobné fnce z repo jako výše
	$ukoly ... //podobné fnce z repo jako výše

	/* příprava dat většinou do pole + nějaký ref na jiné tabulky apod. */
	$data = array('nějaká připravená data');

	$this->template->ukoly = $data['ukoly'];
}

A jestli tomu dobře rozumím – správně bych si měl přidat model Akvizice, který mi vyřeší všechno a vrátí $data a v inject presenteru bude jen akviziceModel $akvModel a ten používám jako službu.

Protože teď mají repositáře jen hloupé metody na svoje tabulky (vyhledejDleId(), vyhledejAktivni(), smazatDleId()). I ref jsem vytahoval až do presenteru. Všechno špatně. :(

Ještě musím zkusit inject konstruktorem do těch modelů.

Editoval kzk_cz (5. 12. 2014 7:55)