Expressive demo

[geerteltink]

It works nicely with expressive, however I would stick a bit more to the default expressive structure. This has a few advantages:

• It's easier when someone wants to change to disco
• You keep the autoload config functionality in case you need to change settings locally for development or production
• I don't think you want everything in that App\Config class. e.g. if you have 50+ routes, you might want them organized within the config/autoload path.
• Eventually it would be easier to integrate with the expressive skeleton

Files you need to get this working:

• ./config/config.php Add this file back and change the last line to

  return $config;

• ./config/container.php

  <?php
  
  use bitExpert\Disco\BeanFactoryConfiguration;
  use bitExpert\Disco\AnnotationBeanFactory;
  use bitExpert\Disco\BeanFactoryRegistry;
  
  // Load configuration
  $config = require __DIR__ . '/config.php';
  
  // Build container
  $beanConfig = new BeanFactoryConfiguration($config['di']['cache']);
  $container = new AnnotationBeanFactory($config['di']['config'], ['expressive' => $config], $beanConfig);
  BeanFactoryRegistry::register($container);
  
  return $container;

• ./config/autoload/disco.global.php

  <?php
  
  return [
    'di' => [
        'config' => \App\Config::class,
        'cache'  => sys_get_temp_dir(),
    ],
  ];

• ./src/App/Config.php Obviously you want that file.

Other files like public/index.php don't need to be changed this way.

And finally integrating this with the expressive installer will be a nice challenge.

• The Disco container should only be available when PHP7+ is detected.
• Testing can be done only when PHP7 is loaded on travis or locally. Maybe check the php version and mark the test as skipped if it's not compatible?
• Some of the standard configuration files need to be changed (like removing dependencies). One solution could be to generate the config files on the fly and use print_r to regenerate those?
• Also ./src/App/Config.php needs to be generated somehow in case different routers and template engines are going to be installed.

/cc @shochdoerfer @weierophinney

[shochdoerfer]

Thanks for the analysis @xtreamwayz. I did remove most of the config files on purpose to make it easier to understand how Disco works. I agree that some parts might not make sense in one big config file, my recommendation for Disco-based configurations is to use Traits to structure the configuration based on slices or functionalities. I am not the biggest fan of Traits but in that context they do work quite well ;)

The biggest problem is really how to generate the config class based on the array-based configuration used by expressive. I remember I discussed this briefly with @weierophinney at ZendCon last year. The installer could be modified to spit out the configuration in an "optimized" form for each supported container but I am not sure how much work that would be or what side effects we would run into.

I am open for anything as long it helps to include Disco in the expressive installer ;)

[geerteltink]

The installer could be modified to spit out the configuration in an "optimized" form for each supported container but I am not sure how much work that would be or what side effects we would run into.

For each container only config/container.php is optimized. Everything else is just messing around with config array files. That's one of the reasons I wanted to leave the config files in tact so whatever router or template engine is installed, the configuration is picked up from those config files. However for disco we would need to change src\App\Config.php as well for each selected option to make it load the factories.

The easiest solution would have been creating that Config class for each possible solution but that's a lot of work for all possible combinations: 4 template renderers (including none), 3 routers and whoops (or not). What's that, like 24 files? And what if more functionality is added.

An other option is to create the code after each selection. I've been looking into this before and that could work. It's pretty easy for array based config however for a class it's a bit more difficult. I think zend-code could do this, but the biggest problem is that the installer runs before any package is installed and we would need to create and maintain that code ourselves.

So that leaves one solution I can think of right now. Create the Config.php file with all possible options. Once an user selects an option all other options for that group (router, template renderer) are removed.

FYI the installer runs before anything else and updates the composer configuration so nothing is available. This is the only way to do this to give a smooth user experience. Otherwise an user needs to run composer update again after the create-project command.

[geerteltink]

Hmmm... just read your comment again. Traits might work as well.

You would create the Config.php class and include a ConfigRouterTrait, ConfigTemplateRendererTrait and a ConfigDebugHandlerTrait (for Whoops).

If we move the container to the first question all following question would know what files to install, either a config file or a trait for the chosen router or template renderer.

[shochdoerfer]

That sounds like a good idea. Do you wanna give it a try or do you want me to start hacking on it?