Can extension load another extension that it is dependent on?

Notice: This thread is very old.
amik
Member | 118
+
0
-

Hi,

Can DI extensions be composed kinda like composer packages?

Let's say my FooExtension depends on loaded BarExtension. I want my FooExtension autoload BarExtension if it wasn't explicitly loaded

I just figured I can override setCompiler() method which is called by Compiler::addExtension like this:

public function setCompiler(Compiler $compiler, $name)
{
	if (count($compiler->getExtensions(BarExtension::class)) === 0) {
		$compiler->addExtension('bar', BarExtension::class);
	}
	return parent::setCompiler($compiler, $name);
}

But it is

  1. ugly
  2. when bar is present in config.neon after foo, it will be loaded twice

so, basically worse than nothing.

If there is currently no way to do this, do you think it would make sense to add support for it?

Tomáš Votruba
Moderator | 1114
+
0
-

Common approach to this is throwing and exception, so user KNOWS it is needed. Let him decide what to do with that.

See:

amik
Member | 118
+
0
-

@TomášVotruba good idea, thanks, but still API for extension dependency would be useful, keeping project's config simpler, don't you think?

srigi
Nette Blogger | 558
+
0
-

@amik there was a beer discussion with David about extensions dependencies/priorities. Currently this is far dream waiting for proper implementation. Priorities based on number (like z-index) is already banned as not good solution to this problem.

What would be appreciated is implementation like Facebook's React Flux Dispatcher – waitFor().

Tomáš Votruba
Moderator | 1114
+
0
-

@amik I'd say this is best practice, as something more complex would require another dependency for every package.

Adding extensions to config as part of README + throwing and exception to user if skipped is just fine. Programmers are very well at exception throwing and they understand them as something is missing/wrong. I'd stick to that in this use case.

There was similar try in Symfony, but not really successful. Again, adding more complexity over framework might lead to not using the feature at all though it's cool and easy to use in the beginning.