I am trying to figure out if SilverStripe 4.2 supports referencing environment variables in the config files in a similar fashion Symfony does.
So far I was able to find the class responsible for building configs, which doesn't seem to have this functionality.
I thought of injecting another layer that would parse the YAML files and process the environment references, but it seems that you cannot extend a service since there is no Dependency Injection container available?
Is there maybe a different way to do this? All that I am trying to do is use environment variables in YAML config files.
You can use environment variables in YAML config provided it's config for the Injector class. You can't use them outside of Injector config (as of 4.2).
You can wrap them in backticks for them to be parsed into config:
SilverStripe\Core\Injector\Injector:
MyServiceClass:
properties:
MyProperty: '`ENV_VAR_HERE`'
Related
The FastAPI application is running on a server and returning some jinja2 templates. The static files are sitting on another server and an nginx serves those. How do I neatly pass the static files url to the jinja2 templates?
There's different approaches to this, but a CDN/static url prefix is usually environment dependent, so it makes sense to declare a env/config variable for this and pass it to the template. The latter can be done using dependency injection or argument passing, or be some global context tag, more on these options can be found in the documentation
Is there best practice to store various config parameters like length of zip code, minimum length of the last name and so on?
I would like something like a php class with static functions and properties, which I can use at any place of my project.
Your looking for parameter service.
In just released Symfony 4.1 by default: https://symfony.com/blog/new-in-symfony-4-1-getting-container-parameters-as-a-service
In older Symfony with package like
https://github.com/Symplify/PackageBuilder/blob/master/README.md#2-all-parameters-available-in-a-service
or own implementation. It's simple :)
In the symfony best pracitces they suggest to use parameters in services.yml that changing, if you will never change this parameter put in Entity as const or in some abstract class that you can create on by yourself.
Documentation about it:
https://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration
For the 3.* branch, I find that the services.yml file is the best place to do so. You can then inject those values into the services that need it, or even access them in your controllers with
$this->getParameter('param_name')
More info on this: see Service Parameters
As other answers point, you can store parameters using the parameters.yml file.
But, for me, you are asking for limitations on entity properties. If you are using Doctrine, you can use annotations for this purpose like described in docs: https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/annotations-reference.html
I've very new to Symfony. Before I've used mostly Laravel.
Lets assume I have an API Key which I want to use here and there thru the project.
It doesn't feel right to store it as a class constant because I can't find any class to keep it in. And it seems pretty dumb to have it in various places thru the app as a string.
Normally using Laravel I would have used a config file specifically for this task.
However in symfony I can't seem to do the same(either that or my google-fu skills are pretty bad). If they are, a simple link to some documentation will do just fine.
So my question is: Where can I store various constants used thru the app?
I'm sorry, but I'm afraid your Google-fu skills let you down this time.
Symfony.com has an excellent article about Configuration: Configuration -
Symfony Best Practices
The common way to save configuration parameters is by using parameters.yml. It supports environment variables as of Symfony 3.2.
The best practice for Symfony 2.x and 3.x:
Define the infrastructure-related configuration options in the
app/config/parameters.yml file.
The best practice for Symfony 4:
Define the infrastructure-related configuration options as environment
variables. During development, use the .env file at the root of your
project to set these.
What is the point of using compiler passes in Symfony?
When we should use Extension class and when Compiler Passes in Symfony?
They come with services definition.
By creating a compiler pass, you are able to update the arguments passed to services.
It's most often done with tagged services.
Also, It can be used for :
Creating new services that require information about other defined services before being defined.
Swapping or adding arguments to a service that you did not write.
Creating and modifying parameters in the container.
I used a compiler pass to register a Factory that make me able to override the doctrine Repository.
You can see the code for more comprehension of how it works:
https://gist.github.com/chalasr/77be8eee5e3ecd3c06ec
Update
Thank's to #Sruj, I added the part I've forgotten about the Extension
Extension are part of dependency injection too, especially of the configuration.
Its primary role is to load the configuration of services across the bundles of your application.
Instead of load your configuration manually by using imports, you can create an extension that does it for you. All your services configuration are registered from your bundle and shared in your whole application.
When you register a vendor in your app configuration, the service container extension of the vendor is invoked.
See "Importing configuration via container extensions" part of the documentation
I was wondering if I could define some variables in parameters.ini and use them in various yml files like validation, routing, etc?
Is this possible?
For any of Symfony2's YAML files that support imports, you can use the following syntax:
imports:
- { resource: parameters.yml }
Of course, this requires a bit of upgrading since parameters.yml is currently Symfony 2.1.x and 2.0.x still uses parameters.ini.
You would be better off passing variables around using service parameters. See this section of the documentation on the service container.
The configuration of validator and routing differs in its implementation.
DependencyInjection configuration files support the imports keyword.
Routing configuration files support the resources keyword.
Validator configuration files do not support import.
Translation configuration files do not support import.