Sebastian Viereck

In Sonata 4 stehen verschiedene Sonata-spezifische Variablen in den Templates zur Verfügung. Hier sind einige der häufig verwendeten Variablen:

1. admin: Diese Variable repräsentiert das aktuelle Admin-Objekt und ermöglicht den Zugriff auf verschiedene Admin-spezifische Informationen und Methoden. Sie kann verwendet werden, um beispielsweise den Admin-Titel oder die Routen zu erhalten.
2. object: Diese Variable repräsentiert das aktuelle Objekt oder die aktuelle Entität, mit der das Template arbeitet. Sie ermöglicht den Zugriff auf Eigenschaften und Methoden des Objekts, um dynamische Inhalte im Template zu generieren.
3. id: Diese Variable enthält die ID des aktuellen Objekts. Sie ist besonders nützlich in Templates, die auf einzelne Objekte angewendet werden, um spezifische Daten abzurufen oder Aktionen durchzuführen.
4. form: Wenn das Template ein Formular darstellt, steht die form Variable zur Verfügung. Diese Variable ermöglicht den Zugriff auf das Formularobjekt und dessen Felder, um beispielsweise Validierungen durchzuführen oder Daten zu verarbeiten.
5. base_template: Diese Variable definiert das Basis-Template, das von einem spezifischen Sonata Template erweitert wird. Sie ermöglicht es Entwicklern, das Standardverhalten von Sonata anzupassen, indem sie ein benutzerdefiniertes Basis-Template festlegen.
6. admin_pool: Diese Variable stellt den Admin-Pool dar und bietet Zugriff auf den gesamten verfügbaren Admin-Bereich. Sie ermöglicht den Zugriff auf Informationen über alle registrierten Admin-Klassen und kann zum Beispiel verwendet werden, um eine Liste der verfügbaren Admin-Objekte anzuzeigen.

In Sonata 4 stehen neben den zuvor genannten Variablen auch die value-Variable zur Verfügung. Diese Variable repräsentiert den aktuellen Wert eines bestimmten Feldes oder einer Eigenschaft des Objekts.

Hier ist ein Beispiel, wie die value-Variable im Template array.html.twig verwendet werden kann:

{% extends '@SonataAdmin/CRUD/base_show_field.html.twig' %}

{% block field %}
    {% if value is not empty %}
        {{ value | join(', ') }}
    {% endif %}
{% endblock %}

protected function configureShowFields(ShowMapper $show): void
{
	$show->add('my_attrbute', null, [
		'label' => 'Array Attribute Example',
		'template' => 'array.html.twig',
		]
	)
}

Um alle Requests und Responses zu loggen, die mittels Guzzle in einer Symfony Applikation getätigt werden, kann man Guzzle folger Maßen konfigurieren:

    guzzle.handler_stack_log:
      class: 'GuzzleHttp\HandlerStack'
      factory: [ GuzzleHttp\HandlerStack, create ]
      calls:
        - [ push, [ '@guzzle.middleware_log', 'log_default' ] ]

    guzzle.middleware_log:
      class: callback
      factory: [ GuzzleHttp\Middleware, log ]
      arguments:
        - '@monolog.logger.my_guzzle_log'
        - '@GuzzleHttp\MessageFormatter'

    GuzzleHttp\MessageFormatter:
      - "Request:\n{request}\nDuration: {req_time}\nResponse:\n{response}\nError:\n{error}"

Damit werden alle Logs nach zum Monolog Service monolog.logger.my_guzzle_log weitergeleitet.

Der MessageFormatter unterstützt verschiedene Formatzeichenfolgen, die Sie in Ihren Protokollen verwenden können. Hier sind fünf nützliche GuzzleHttp\MessageFormatter-Formate:

1. Log-Eintrag, der die URL, Methode, und Status-Code umfasst: Format: "Request: {method} {uri}, Response: {code}"

Beispiel Output: "Request: GET http://example.com, Response: 200"

2. Log-Eintrag, der die Anforderungsdauer und den Antwortstatus beinhaltet: Format: "Duration: {req_time}, Response: {code}"

Beispiel Output: "Duration: 1.123, Response: 200"

3. Log-Eintrag, der die Anfrage, Antwort und etwaige Fehler anzeigt: Format: "Request:\n{request}\nResponse:\n{response}\nError:\n{error}"

Beispiel Output:

Request:
GET / HTTP/1.1
Host: example.com

Response:
HTTP/1.1 200 OK
Content-Length: 348
Content-Type: text/html

Error:
None

Der GuzzleHttp\MessageFormatter unterstützt eine Vielzahl von Platzhaltern, die in den Formatstrings verwendet werden können. Hier ist eine Liste einiger der verfügbaren Platzhalter:

Um die Monolog-Logs in der Symfony-Konsole anzuzeigen, können Sie Folgendes tun:

1. Sie müssen zuerst sicherstellen, dass Monolog so konfiguriert ist, dass es auf der Konsole loggt. Dazu müssen Sie die config/packages/dev/monolog.yaml-Datei bearbeiten und sicherstellen, dass eine Stream-Handler-Konfiguration für die Konsole vorhanden ist.

monolog:
    handlers:
        console:
            type:   stream
            path:   "php://stdout"
            level:  debug
            channels: ["!event"]

2. Es empfiehlt ich auch beim ausführen der Tests den Consolen Logger zu aktivieren in config/packages/test/monolog.yaml. Damit erhält man wertvolle Loginformationen beim Ausführen seiner Tests.

2. In Ihrem Konsolenbefehl können Sie dann das Logger-Interface injizieren und verwenden, um Meldungen zu loggen. Hier ist ein einfacher Konsolenbefehl, der dies demonstriert:

namespace App\Command;

use Psr\Log\LoggerInterface;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class YourCommand extends Command
{
    private $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;

        parent::__construct();
    }

    protected function configure()
    {
        $this
            ->setName('app:your-command')
            ->setDescription('Description of your command.');
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $this->logger->info('This is an info log entry.');

        // ...

        return Command::SUCCESS;
    }
}

3. Starten Sie dann Ihren Befehl von der Konsole aus, und Sie sollten die Protokolle auf der Konsole sehen:

$ php bin/console app:your-command

[2023-06-02T12:34:56.789Z] info: This is an info log entry.

Bitte beachten Sie, dass die obige Konfiguration die Logs auf allen Kanälen außer „event“ auf „php://stdout“ ausgibt. Sie können die Kanäle an Ihre Bedürfnisse anpassen.

Ebenfalls beachten Sie bitte, dass die Protokolle nur ausgegeben werden, wenn der Log-Level Ihrer Meldung dem in der Monolog-Konfiguration festgelegten Level entspricht oder darüber liegt. Im obigen Beispiel wird alles auf „debug“-Level und darüber protokolliert.