Kdyby\Events, circural reference – asi Gedmo

Zdravím,
narazil jsem nyní na stejný problém. Povedlo se ti to nějak vyřešit?

K cemu potrebujes predavat $em?
V configu muzes predat do fasady rovnou dao.

services:
    - DiscussionFacade(@doctrine.dao(Conversation))

Už posílám pull-request s fixem

Edit: je to tam: https://github.com/…ents/pull/39

Editoval Michal Vyšinský (21. 3. 2014 14:00)

Z jednoho EntityDao se dá získat Dao pro související entitu metodou related.

Chyba je v Gedmu, protože je to sračka a na každej pageload inicializuje všechny listenery. Odmítám to podporovat.

Gedmo můžeš forknout a opravit. Je to lepší řešení než to opravovat v Kdyby, protože gedmo touhle hovadinou zabíjí výkon, protože ti na každej request inicializuje celej graf objektů kterej se dotýká listenerů.

Spíš jsem myslel něco jako udělat analýzu v compile-time v nějakém CompilerExtension pro gedmo a ten treerepo upravit tak aby přijímal ten listener nějakou inject metodou nebo takněco a nevolal to v konstruktoru. Tím si ušetříš to že to vytváří ty listenery runtime.

Klidně bych na to něco přidal do EventsExtension aby sis mohl říct o nějaké konkrétní listenery, nebo si je profiltrovat sám.

Tohle by ti mělo vrátit všechny listenery už teď, pokud to zavoláš v beforeCompile:

$builder->findByTag(\Kdyby\Events\DI\EventsExtension::SUBSCRIBER_TAG)

Já sem pro přepsání pár vzorů z Gedma hlavně stromy do nové knihovny. Určitě bych ji otestoval.

Jestli myslíš předání přes constructor injection, tak to nějak orzumně nejde. Protože je ta repository class volána z EntityManageru jako new *Repository(); s DI se tam asi moc nepočíta…

Problém je v tom, že gedmo je určen pro Doctrine a čistá doctrine žádné lazy listenery nemá, tedy z jejich pohledu v tom není vůbec žádný problém a nejspíš to tam nikdy neprotlačíš.

Tak kdyby někdo řešil podobný problém jako já, tak jsem to nakonec vyřešil takto. Šlo mi o to, abych nemusel zasahovat do jednotlivých repositories přímo do Gedma. Řeším konkrétně TreeRepositories.

Udělám si vlastní repository, která dědí od té konkrétní v Gedmu a pak ji samozřejmě nastavím těm entitám:

class NestedTreeRepository extends \Gedmo\Tree\Entity\Repository\NestedTreeRepository
{

	public function __construct(EntityManager $em, ClassMetadata $class)
	{
		$this->_entityName = $class->name;
		$this->_em = $em;
		$this->_class = $class;
	}

	public function setTreeListener($treeListener)
	{
		$this->listener = $treeListener;
		if (is_null($this->listener)) {
			throw new \Gedmo\Exception\InvalidMappingException('Tree listener was not found on your entity manager, it must be hooked into the event manager');
		}

		if (!$this->validate()) {
			throw new \Gedmo\Exception\InvalidMappingException('This repository cannot be used for tree type: ' . $this->getStrategy($em, $class->name)->getName());
		}

		$this->repoUtils = new RepositoryUtils($this->_em, $this->getClassMetadata(), $this->listener, $this);
	}

}

Překryl jsem konstruktor, a ty věci z něj jsem dal až do setteru listeneru.

Potom jsem si udělal subscriber pro Kdyby\Events, které na slouchá na událost kdy se :

class GedmoSubscriber extends Object implements Subscriber
{

	private $container;

	public function __construct(\Nette\DI\Container $container)
	{
		$this->container = $container;
	}

	public function getSubscribedEvents()
	{
		return array(
			'Kdyby\Doctrine\EntityManager::onDaoCreate',
		);
	}

	public function onDaoCreate($em, $dao)
	{
		if($dao instanceof \JiriNapravnik\Gedmo\Tree\Entity\Repository\NestedTreeRepository){
			$dao->setTreeListener($this->container->getService('gedmo.gedmo.treeable'));
		}
	}
}

není tam moc hezké tahání te pojmenované service, ale je to kvůli tomu, že jak Rixxi\Gedmo tak Zenify mají u listenerů (nevím proč) autowired:no. Řešením je případně si to forknout a autowiring zapnout.

Já mám tedy ještě tu TreeRepository gedmackou podedenou od EntityDao – protože chci pohodlně volat save a remove. Ale to není nutné. funguje to i bez toho. Skoda, že to entitydao nejde použít mj jako tratia, pak by se to dalo používat i k rozšíření vlastních repository class, které už dědí od Doctrine\EntityRepository

Myslíš jako udělat si tu vlastní Repository jako službu a tam to nastavit? To jsem se pokoušel prvně, ale dělá mi tam problém to, že tu DAO (pochopitelně) vytváříš v EntityManageru přes new:

$dao = new $daoClassName($this, $metadata);

Či-li já když si udělám tu mojí treeRepository jako službu, tak ta setup se použije sice tam, ale pak když se to vytvří přes new, tak si tu už to nastavení nenese…

Nemluvě o tom, že když si to dám jako service, tak se to snaží autowirovat EntityManager (coz je v pohodě) ale pak i ClassMetadata, což nejde