Als Fortsetzung unserer Hands On ez Publish 5 – Reihe und vor allem als Fortsetzung des Blogeintrags von Thomas Zinnbauer Hands On eZ Publish 5: Der eZ Publish 5 Profiler, ein eigener Data Collector, wollen wir mit eZ Publish 5 und dem Profiler weiter experimentieren und dabei versuchen eZ Debug – Ausgaben in den Profiler rein zu bekommen.

Es ist seitens eZ von vornherein geplant gewesen, die eZ-Debug-Ausgaben in dem Symfony2 WebProfiler anzuzeigen (das wurde von einem eZ Entwickler im offiziellen eZ Forum erwähnt), deswegen gibt es im eZ Publish 5 keine Frontend-Debug-Ausgaben mehr, auch wenn man versucht, sie mittels ini-Dateien einzuschalten. Alle Manipulationen mit ini-Dateien führen ausschliesslich im Admin-Bereich zum gewünschten Resultat, im Frontend passiert jetzt gar nichts mehr. Die Profiler-Lösung existiert aber auch noch nicht. Und wir wollen jetzt versuchen, die Debug-Ausgaben, die für uns im Moment greifbar sind, im Profiler anzuzeigen.

Dazu muss man noch zusätzlich anmerken, dass das gesamte Debugging von eZ noch nicht auf die neue Version umgestellt wurde, deswegen debuggt es jetzt ausschliesslich “legacy”-Bestandteile, das heisst, dass z.B. nur die alten eZ Templates (.tpl), aber nicht die neuen twig-Templates als Templates erkannt und in der Debug-Ausgabe auch als solche aufgelistet werden. Deswegen sieht unsere Debug-Ausgabe im Profiler zwar etwas mager aus, aber dafür kommt sie von dem richtigen Ort und wird auch an der richtigen Stelle angezeigt. Das ist für den aktuellen Zeitpunkt völlig ausreichend, damit kann man erfolgreich arbeiten.

Wir fangen also dort an, wo Thomas im vorherigen Blogeintrag aufgehört hat und brauchen alles, was in seinem Beitrag beschrieben ist, um weiter zu machen.

Wir wollen nämlich unseren eZ Frontend Debug an Stelle von “Fill me with loads of eZ-Debug Data” ausgeben (siehe Screenshot oben).

Hier ist die Datenstruktur, wie sie am Ende aussieht:

Den gesamten Code zu diesem Blogbeitrag kann man hier anschauen: https://github.com/ymc-elst/blogging-code-examples/tree/master/2012-09-27-eZ5-Debug-Output-in-Profiler

Um an die Daten aus der eZ-Debug-Ausgabe zu kommen, müssen wir in unserem Symfony Bundle eine Möglichkeit haben, auf die eZ Klassen zugreifen zu können. Dafür bauen wir einen Controller, den EzPublishDebugController.

EzPublishDebugController erweitert die “Controller”-Klasse aus dem EzPublishCoreBundle, und somit bekommen wir die Möglichkeit, durch den Aufruf $this->getLecacyKernel()  auf die eZ-Funktionalitäten zuzugreifen, wie z.B. hier auf eZDebug:

Die Controller-Klasse kann man natürlich auch als richtigen Controller verwenden, oder auch, wie wir es hier machen werden, aus dem DataCollector aufrufen.

Hier ist die neue Klasse EzPublishDebugController.php

Sie lädt Debug-Ausgaben für eine bestimmte Content-Id und gibt sie formatiert zurück. Für die Formatierung haben wir ein twig-Template erstellt (ezpublishdebug.html.twig).

Natürlich müssen wir unseren neuen Controller noch dem System bekannt machen:

EzPublishProfilerBundle/Resources/config/routing.yml

und die EzPublishProfilerBundle/Resources/config/services.yml erweitern (die letzten 4 Zeilen):

Und somit haben wir jetzt einen Controller, den wir auch separat nutzen können. Mit dem Browseraufruf: http://…/ezpublish5/web/index.php/profilerDebug/1 (1 ist die Content-Id) bekommen wir folgende Ausgabe:

 

 

 

 

 

Jetzt sind wir endlich soweit, dass wir auch unseren EzPublishDataCollector updaten können, sodass er die Debug-Ausgaben, die wir auf dem Screenshot oben sehen, aus dem Controller holt und in dem Profiler anzeigt.

So sieht EzPublishDataCollector nach dem Update aus:

Wir erstellen eine neue Funktion, die ezDebugInfo($content_id) heisst, und sie wird durch die Zeile 28 aufgerufen

und somit wird das Resultat an das Template ezpbulishdata.html.twig übergeben. Dieses Template müssen wir nicht ändern, da wir jetzt einfach statt der Ausgabe “Fill me with loads of eZ-Debug-Data”, unsere echte Debug-Ausgabe übergeben.

Weiter gibt es einige wichtige Sachen zu beachten:

Damit wir auf den Controller von unseren neuen Funktion aus zugreifen können, müssen wir irgendwie an das Objekt $container (Service Container) kommen. Das geschieht in zwei Schritten. Zuerst müssen wir in unserer Klasse einen Konstruktor erstellen:

Danach müssen wir sicherstellen, dass bei dem Klassenaufruf dieser ContanerInterface $containertatsächlich übergeben wird.

Das erreichen wir dadurch, dass wir in der Datei services.yml (siehe oben) die Zeile 5 erweitern, und schreiben dort

Jetzt, wo wir den Container haben, können wir auch auf unseren Controller zugreifen.

Das passiert entweder durch das Initialisieren der Controller-Klasser mit neu, oder, wie man oben im Code sieht, durch das Rausholen des Controller-Objekts aus dem Container.

Hier ist wichtig zu wissen, dass beide in dem vorherigen Satz beschriebenen Methoden zunächst zu einem komplett leeren Objekt führen. Erst duch die Zeile 39 wird das Objekt befüllt:

Danach kann man ganz normal auf die einzelnen Methoden des Objekts zugreifen und auch die lang ersehnte Debug-Ausgabe in den Symfony Profiler bekommen:

Wie oben bereits erwähnt, ist die Debug-Ausgabe hier nicht so umfangreich, wie man von eZ 4 gewohnt ist, aber das liegt daran, dass eZ 5 noch in Kinderschuhen steckt. Dafür hat man aber hier ganz viele Möglichkeiten weiter zu entwickeln, mitzuwirken und eigene Ideen an eZ 5 direkt beizusteuern.

This blog post is also available in English.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *