Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow a config array for the container, instead of a path #83

Open
finn-matti opened this issue Oct 5, 2021 · 4 comments
Open

Allow a config array for the container, instead of a path #83

finn-matti opened this issue Oct 5, 2021 · 4 comments

Comments

@finn-matti
Copy link

finn-matti commented Oct 5, 2021

Feature Request

Q A
New Feature yes
RFC no
BC Break no

Summary

It would be great if the ContainerResolver could accept an array as its configuration instead of a path. This would make it function similarly to the mvc skeleton's index.php:

$appConfig = require __DIR__ . '/../config/application.config.php';
if (file_exists(__DIR__ . '/../config/development.config.php')) {
    $appConfig = ArrayUtils::merge($appConfig, require __DIR__ . '/../config/development.config.php');
}

// Run the application!
Application::init($appConfig)->run();

This is great because it allows you to merge another configuration file into the config.

With laminas-cli this is currently not possible, it seems. Or maybe I just don't know how?

@froschdesign
Copy link
Member

@finn-matti
Something like this: #78 (comment) ?

@finn-matti
Copy link
Author

I guess that would work. However I still think being able to stick an array in the ContainerResolver would be nicer for folks like me, who have to use laminas-cli through an index.php instead of the provided binary because of requirements I can't change.

@froschdesign
Copy link
Member

I guess that would work.

Yes, the workaround from #78 works but it is still a workaround and the feature should be implemented.


The goal of #78 and your feature request is the same, right?

@finn-matti
Copy link
Author

The goal of #78 and your feature request is the same, right?

Yes. The end goal is the possibility of optional includes. But: Preferably as an array, that can just be handed over to the ContainerResolver. Since I didn't see anything as regards to the last part of my request (except that the current solution is a workaround, which lets me infer stuff, but I am not yet certain which is why I'm weaseling around here… apologies!): if the last part of my request would be added to that request explicitly, this one could be closed, as far as I am concerned. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants