Closed geerteltink closed 6 years ago
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 ;)
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.
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.
That sounds like a good idea. Do you wanna give it a try or do you want me to start hacking on it?
It works nicely with expressive, however I would stick a bit more to the default expressive structure. This has a few advantages:
config/autoload
path.Files you need to get this working:
./config/config.php Add this file back and change the last line to
./config/container.php
./config/autoload/disco.global.php
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.
./src/App/Config.php
needs to be generated somehow in case different routers and template engines are going to be installed./cc @shochdoerfer @weierophinney