config/config.yaml

[462]

Ich möchte für ein Bundle eine eigene Konfiguration definieren. Im Bundle-Ordner habe ich eine config/config.yaml mit einem parameters: Bereich angelegt.

parameters:
    para1: 'xyz'
    para2: 'abc'

$this->Config

gibt die Werte meiner config.yaml aber nicht aus.

Nach langem Suchen habe ich (finde ich) eine recht aufwändige Grundvariante für Symfonie allgemein gefunden https://stackoverflow.com/questions/...ile-for-bundle.

Wie bekomme ich die Parameter am einfachsten und saubersten in mein Bundle? Ist das wirklich so aufwändig?

[zoglo]

Wie bekomme ich die Parameter am einfachsten und saubersten in mein Bundle? Ist das wirklich so aufwändig?

Genau so, wie in deinem Beispiel.

Oder du nutzt ENV

[BugBuster]

Das twitter Beispiel aus Stack Overflow kam mir bekannt vor. Hab's in meiner Sammlung gefunden: https://symfony.com/doc/current/bund...iguration.html

[462]

Vielen Dank für die Hinweise. Leider muss man sich die Informationen über die verschiedenen Symfony Versionen und die Abwandlungen durch Contao etwas zusammensuchen. Aktuell funktioniert es für mich am Besten in der nachfolgenden Art und Weise.

1. Einlesen der config/config.yaml (und einer config/service.yaml) ins Bundle entsprechend der Entwickler-Doku (https://docs.contao.org/dev/getting-...-configuration). Mit erster Import-Zeile wird die Konfigurationsdatei bereits in den Applikations-Container eingelesen.

<?php
// scr/MyAppNameBundle.php

declare(strict_types=1);

namespace IAmVendor\MyAppName;

use Symfony\Component\HttpKernel\Bundle\AbstractBundle;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;

class MyAppNameBundle extends AbstractBundle
{
  public function loadExtension(array $config, ContainerConfigurator $container, ContainerBuilder $builder): void
  {
      $container->import('../config/config.yaml');
      $container->import('../config/services.yaml');
    }
}

Leider ist jedoch der Zugriff auf den Container in den Contao-Klassen wohl nicht ohne weiteres gegeben, wenn man zum Beispiel aus den Callbacks der dca-Konfigurationen darauf zugreifen möchte (https://community.contao.org/de/show...l=1#post533196). Die in den Symfony-Beispielen angegebenen Verfahren mit einer Dependency-Injection in die jeweilige Klasse funktioniert also so nicht direkt.

2. Die Alternative, die bleibt, ist eben einen eigene Klasse (für eine Dependency-Injection) beziehungsweise direkte einen Service zu erstellen, der die Parameter intern bereitstellt. Damit eine derartige Klasse als Service eben allgemein und universell (und sogar einmalig) bereitgestellt wird, ist die oben angegebene config/service.yaml erforderlich.
Cool sind hierbei die beim aktuellen Symfony bereitgestellten Attribute zur Verknüpfung der Parameter (https://symfony.com/doc/current/serv...utowiring.html), die einen speziellen Zugriff auf den $parameterBag des Containers stark vereinfachen.

<?php
// scr/Constant.php

declare(strict_types=1);

namespace IAmVendor\MyAppName;

use Symfony\Component\DependencyInjection\Attribute\Autowire;

class Constant
{
    public function __construct(
        #[Autowire(param: 'para1')]
        protected string $para1,

        #[Autowire(param: 'para2')]
        protected string $para2,
    ) {
    }

    public function __get($property) {
      if (property_exists($this, $property)) {
        return $this->$property;
      }
    }
}

3. Nun kann dieser "Constant"-Service in einer abgeleiteten Contao-Klasse verwendet werden.

<?php
//contao/dca/tl_...

declare(strict_types=1);

use Contao\System;

...

class tl_... extends Contao\Backend {

    public function __construct(private string $param1) {   
      $constant = System::getContainer()->get('IAmVendor\MyAppName\Constant');
      $this->param1 = $constant->$param1;
    }
}

[Spooky]

Das brauchst du nicht, du kannst auch einfach

System::getContainer()->getParameter(…) 

in solchen Legacy Klassen nutzen.

[Spooky]

Leider ist jedoch der Zugriff auf den Container in den Contao-Klassen wohl nicht ohne weiteres gegeben, wenn man zum Beispiel aus den Callbacks der dca-Konfigurationen darauf zugreifen möchte

Für Callbacks kannst du auch DI verwenden. Siehe https://docs.contao.org/dev/framewor...ring-callbacks

[462]

Also bin ich doch noch etwas mehr von hinten durch die Brust ins Auge unterwegs gewesen, als notwendig war. Für den Lerneffekt aber ganz gut.

Hat die Einbindung der Callbacks per Attribut eigentlich noch mehr Vorteile außer die Möglichkeit der Dependency-Injection und dass ich vielleicht näher am originären Symfony selbst bin?
Ich verteile doch zusammengehörige Funktionalitäten auf verschiedene Dateien, was die Übersicht nach meinem Empfinden nicht wirklich fördert.

[Spooky]

Hat die Einbindung der Callbacks per Attribut eigentlich noch mehr Vorteile außer die Möglichkeit der Dependency-Injection und dass ich vielleicht näher am originären Symfony selbst bin?

Sauberes programmieren zB

[462]

Ich habe gerade zwei Attribut-Definitionen (#[AsHook('...')] und #[Autowire(param: 'para1')]) für einen Hook-Service kombiniert, was, wie ich finde, schon eine echt elegante Lösung darstellt. So wird auch die Ausgliederung der Klassen beispielsweise für die Callbacks aus den dca-Definitionsdateien wirklich richtig sinnvoll.

...
use Contao\CoreBundle\DependencyInjection\Attribute\AsHook;
use Symfony\Component\DependencyInjection\Attribute\Autowire;

#[AsHook('XXX')]
class XXXListener
{   
    public function __construct(
        #[Autowire(param: 'param1')]
        protected string $param1
        ) {
        }

    public function __invoke() {
        $x = $this->param1;
        ...
    }
}