Extending extensions – solid modular concept

This looks great! Finally a complex solution to extensions that could make it to Nette because it seems to be a “Nette way”.

I was not sure at first, but it looks very useful to me now. I'll give it a try.

One minor detail. I'd to change the scanning to this (would require small change in Nette):

foreach ($this->compiler->getExtensions('Kdyby\Doctrine\DI\IEntityProvider') as $extension) {
	$metadata = $extension->getEntityMappings();
	Validators::assert($metadata, 'array:1..');
	$config['metadata'] = array_merge($config['metadata'], $metadata);
}

I put together package.

Before you use it understand that it will change without warning and when support for this is introduced to Nette its development will stop.
It might be possible in that case that compatibility package will be released but highly improbable as I got shit to do.

composer require rixxi/modular:@dev
source is at github

On the other side I find this approach very useful and this or similar interface will be highly used by other Rixxi packages. rixxi/user is one of them.

Last edited by mishak (2013-07-21 17:39)

“ModuleExtension” sounds to me like jabklové jablko, what about NamedExtension?

Oh YEAH! It sounds good ..

This is exactly what I need. I used Doctrine (Kdyby\Doctrine) too, and now I do it like COPY&PASTE between projects :(

It's a pitty that Nette prefer NDB, so this concept isn't useful for common nette, because this concept can provide a new possibilities of add-ons.

Last edited by frosty22 (2013-07-22 11:19)

mishak wrote:

Mine version is for Nette @dev only and therefore module registration should be done in extensions section of config. There is no easiest way then adding one line to config. I generally hate idea of non-explicit configuration of any sort.

Flame/Modules are only working with @dev Nette too. :-)

But registration of modules cannot be register in extension (I tried it ;)). Modules must be registered before building of system container (just in bootstrap) because you don't have available all loaded extensions from method loadConfiguration() in specific extension and therefore e.g. IEntityProvider for Kdyby/Doctrine is not working.

//EDIT:
And the next problem is that if you will be register modules from extension, you cannot add some additional config files into system container :-)

Last edited by sifik (2013-07-22 12:12)

I agree! Config files are temporary solution until all providers are full supported or implemented.

Composer installer was very good idea. Well, I did the custom composer installer for nette modules. The installer will be adding (or removing) extension class into your extensions.(neon | php) file.

It's very flat ;-)

Last edited by sifik (2013-07-26 10:46)

Added tests, examples & working demo for Flame/Modules! Brand new homepage http://flame-org.github.io/Modules/ :)

Just FYI, on the last Nette Framework meetup, David agreed that my RFC should be added into Nette's extension.

If you have better idea how to register tracy and bar panels please write your own RFC, ideally before I start to implement it ;)

As I've been poking around nette/bootstrap#4 I realized this can work well only for really core features in the current component-based status quo.

Take for example Tracy (bar) panels.
Where would you put the provider interface? I guess into Tracy, right? OK, you've just introduced a hard dependency on Tracy to any component that wants to be able to provide Tracy panels – not good at all.
OK, next idea… the interface could be placed into some really core package. Like utils? Nonsense, why would the provider interface be in a package with no provider and no consumer?
OK, next idea… how about a new package for the interface – kind of works, but it's really weird to have a package with only one interface.
OK, next idea… how about reversing the relation and instead of providers introduce consumers? That could work, but the only reason to have for this a consumer interface is the possibility to replace the default consumers by our own. Well, then your back to square one – in order to replace the consumer you need to depend on their package to get the interface.

I would suggest this: If you expect that your extension will be configured from other extensions, you should provide a public API for that (within the extension class). So, other authors won't need to directly mess around with the configuration of your services, they simply check if your extension is enabled and use its API. Examples for this might be TracyExtension (does not exist yet), LatteExtension, WebLoader, Translators, …

Guys, how do you solve the problem, when some INiceThingProvider extends Nette\DI\CompilerExtension but needs some extra dependencies to generate actual return values in INiceThingProvider::someMethod()? For example Nette\Security\User or Nette\Localization\ITranslator.

use Nette\DI\CompilerExtension;
use Nette\Security\User;

class MyExtension extends CompilerExtension implements \INiceThingProvider
{
    // this kind of dependency is bad :(
    public function __construct(User $user)
    {
        $this->user = $user;
    }

    /**
     * INiceThingProvider::coolMethod()
     *
     * @return array
     */
    public function coolMethod()
    {
        return [
            'title' => $this->user->identity->name,
            ...
        ];
    }

    public function beforeCompile()
    {
        foreach ($this->compiler->getExtensions('INiceThingProvider') as $extension) {
            $extension->coolMethod();
            // add services, setups etc.
        }
    }
}

I like the solid modular concept but it seems that in this case, MyExtension itself cannot be INiceThingProvider but another class needs to be introduced to accomplish the desired result but in that case, it would not be CompilerExtension so it would not be accesible via Compiler::getExtensions($type) method…

Last edited by JuniorJR (2015-06-30 21:53)

@MichalVyšinský I think it makes sense, I do some stuff using ContainerBuilder like adding services and setups depending on what returns INiceThingProvider::coolMethod() method. The only solution is add separate service which will implement the logic, isn't it?

Last edited by JuniorJR (2015-06-30 22:09)