Moduly – podstrčit různé třídy na různých projektech

Přesně tak, řešil bych to pomocí interface. Přesně kvůli tomu jsem začal hodně programovat proti interface. Dřív jsem měl konkrétní třídy, ale začal jsem používat Doctrine a když jsem potom chtěl nějakou knihovnu zpětně použít ve starším projektu, tak to byl trochu problém.

Myslím si, že interface je nejlepší cesta, ale třeba má někdo lepší řešení…

Mám to zhruba takhle pro jednodušší použití

if($config['test'])
{
	$mailer = $builder->getDefinition('nette.mailer')
		->setFactory('\JanDrabek\MailPanel\SessionMailer');
	$mailer->addSetup('\JanDrabek\MailPanel\MailPanel::register(?, ?)', array('@http.request', '@nette.mailer'));
} else
{
	$builder->getDefinition('nette.mailer')
					->setClass('\Nette\Mail\SmtpMailer', [$config['SMTP']]);
}

Ale neměl by být problém např. definovat si jméno služby a pokud ta služba existuje, tak ji použít jinak jinou. Nebo si předat do configu třídu, která se má použít. Uměl bych si představit něco jako

articleExtension:
	form: \ArticleModule\Compoenent\Form\ThisProjectForm

a v loadConfiguration

$builder->setDefinition($this->prefix('form'))
	->setClass($config['form']);

@akadlec: Registruji pres flame/modules, takze tedy kazdy modul ma vlastni CompilerExtension

Nicméně ty moduly jsou komplexni, takze maji nejen modelove tridy, ale samo i presentery a sablony. Sablony nejsou problem, ty si muzu dat ven a pri vykresleni jen zkontroluji je tam nejaka vlastni sablona? Pokud ne, dam tu defaultni.

Problem je momentalne hlavne s temi modelovymi tridami. Rekneme, ze zaklad ulozi nejaky zakladni clanek. Pak mam ale clanek, ktery ma dalsi atributy a potrebuji tedy resit dalsi ulozeni. Prijde mi nejlepsi asi jak resi @Oli, a ta fasada bude implementovat interface, a nastavim tu fasadu, kterou budu potrebovat v CompilerExtension.

Ještě mě napadá nařešil jste někdo překrytí Presenteru? Podle mě to asi nějak rozumně nepůjde jelikož bych musel upravit i Router s tím související…

@Oli díky za tip, to zní docela rozumně. I když zase teď neřeším úplně stoprocentní přenositelnost, tak jestli to není až moc velký kanon na vrabce, ale někdy jistě použiju:)

No já to dělám trochu jinak. Mám nějakej DefaultArticlePresenter a z něj (za všech okolností) dědí ArticlePresenter. Ten default nemá ani šablonu u sebe má jen nějaký defaultní chování. Proto mě sedí všechny odkazy.

Tvůj případ nevím úplně jak bych řešil. Možná si do toho ArticleModule\FrontModule\ArticlePresenter vytáhnout informaci jakej router je použitej a s 301 přesměrovat na OverrideModule\FrontModule\ArticlePresenter. Jinak mě nic pěknýho momentálně nenapadá…

@JiříNápravník No to ano. Ono to je trochu schizofrenní, ale čím víc nad tím přemejšlím, tím víc se mě to asi líbí. Jde to to, že Ten default má celou logiku a je to vlastně abstraktní třída. To jsem vlastně nezmínil, protože to tak explicitně napsaný nemám, ale je to dost podstatný. A vždycky musí dědit jinej presenter.

Ten default je ve vendoru načítanej composerem (ArticleModule, PageModule, …) a drží si to, co je v 90% případů potřeba (default, detail – frontend; default, edit – admin) + nějaký drobnosti. No a v prohlížeči se k „němu“ nikdy nedostaneš, protože je abstract. Ale podědí si ho jinej presenter, kterej, pokud není potřeba nic jinýho, tak je jen prázdná třída. Ale co je důležitý, má konkrétní jméno a konkrétní šablony. Tenhle konkrétní presenter je už v app a je teda projekt od porojektu jinej. Zatímco ten default je v modulu a pro všechny konkrétní projekty je totožnej.

Tak snad jsem to vysvětlil trochu líp.

Jasně, v tom případě by asi šlo mít zapnutý procházení i těch modulů a pokud se něco změní, tak odstranit ze seznamu povolených umístění presenterů ten modul a nově vytvořený presenter (se stejným názvem) vložit jinam.

Nevím jak jinak udržet modul totálně nezávislej na projektech. Taky to tak mám, že většina presenterů je prázdných a jsou tam v podstatě jen kvůli routování/rozšířitelnosti. Pokud by měl někdo lepší nápad jak to řešit, tak se taky nechám rád poučit :-)