In eZ Publish 5 übernehmen fortan Symfony-Controller die Aufgabe der Module aus eZ Publish 4. In unserem letzten “Hands on”-Artikel zu eZ Publish 5 haben wir das anhand eines Beispiels gezeigt, in welchem wir einen Controller samt Twig-Template für die rudimentäre Anzeige eines Inhaltobjekts entwickelt haben. An dieser Stelle möchten wir dagegen das Anzeigen von Inhaltsobjekten nicht allein unter dem Aspekt betrachten, eine Seite mit mehr als nur “Hello World” zu füllen. Stattdessen interessiert uns, wie man eine in eZ Publish 4 bestehende Funktionalität nach eZ Publish 5 migrieren könnte. Und selbstverständlich gibt es in eZ Publish 4 bereits eine Möglichkeit, Inhaltsobjekte in verschiedenen Ansichten anzuzeigen – nämlich in Form des Content-Moduls. Für unser Konzept einer modulweisen Migration von eZ Publish 4 auf eZ Publish 5 wollen wir uns deshalb mit genau diesem Modul näher beschäftigen.

Der Einfachheit halber beschränken wir uns auf die Plain-Ansicht des Content-Moduls. Zunächst legen wir in unserer frischen Installation von eZ Publish 5 ein neues Bundle FooBarBundle an, das die migrierte Funktionalität enthalten soll. Da wir schon im letzten Blogartikel ausführlich erläutert haben, wie man ein Bundle neu anlegt, wollen wir an dieser Stelle nicht näher darauf eingehen. Unser Bundle könnte beispielsweise in src/Foo/BarBundle/ angelegt sein:

https://gist.github.com/3098735#file_foo_bar_bundle.php

Bei der Konfiguration des Routing ist zu beachten, dass die URL für die Anzeige eines Inhaltsobjekts in der Plain-Ansicht auf unseren Controller verweist. Andernfalls würde einfach ein Fallback auf das Modul in eZ Publish 4 stattfinden – wie bei allen anderen URLs, die nach der URL-Systematik von eZ Publish 4 aufgebaut sind. Die Routenkonfiguration könnte folgendermassen aussehen.

https://gist.github.com/3098735#file_routing.yml

Nun kommen wir zum eigentlich spannenden: Die Implementierung des Controller Location mit der Action viewPlain, auf die die obige Route verweist. Unter der Prämisse, dass wir die Funktionalität “Anzeige eines Inhaltsobjekt in einer bestimmten Ansicht” neu als Controller(-Action) umsetzen wollen, während wir die dazugehörigen Templates möglichst beibehalten wollen, könnte unser Controller so aussehen:

https://gist.github.com/3098735#file_location_controller.php

An erster Stelle holen wir das Inhaltsobjekt, welches wir anzeigen möchten. Das geschieht anhand der in der URL übergebenen Location-ID (sinngemäss die Inhaltsknoten-ID aus eZ Publish 4). Somit erhalten wir das Objekt in einem Location-Objekt gekapselt und übergeben es anschliessend einem Template, das in der von eZ Publish 5 verwendeten und von den Machern von Symfony 2 entwickelten Template-Sprache Twig verfasst ist. Das Template wiederum übergeben wir – fertig gerendert – an ein weiteres Twig-Template. Die zweifache Template-Einbindung im Controller ist nötig, da wir ja die bestehenden Templates aus eZ Publish 4 samt deren interner Struktur verwenden möchten. In unserem Fall haben wir es mit den Templates pagelayout.tpl und node/view/plain.tpl zu tun. Ersteres zeigt sich lediglich für die generelle Darstellung der ausgelieferten Webseite verantwortlich und greift für den eigentlichen Seiteninhalt auf das andere Template zurück. Zwar handelt es sich im Controller erkennbar um Twig-Templates, diese wrappen jedoch nur die bestehenden Templates über die von eZ Systems auf Basis von Symfony 2 zur Verfügung gestellt Legacy-Template-Unterstützung (ez_legacy_include) und bestehen somit lediglich aus einem Mapping von Template-Platzhaltern:

https://gist.github.com/3098735#file_layout.html.twig

Es muss dazugesagt werden, dass hier nicht alle Template-Platzhalter berücksichtigt sind. So fehlen z.B. jene für den Seitentitel und die Breadcrumb-Navigation. Abgesehen davon sollte die Webseite hinter unserer auf den Controller verweisenden URL aber identisch aussehen mit jener, die man bekäme wenn das Fallback auf eZ Publish 4 nicht umgangen wäre – schliesslich haben wir die Funktionalität ohne Aenderungen nachgebaut. Ein Vergleich bestätigt das:

Anzeige des Ordners mit Inhaltsknoten-ID 2 in der Plain-Ansicht in eZ Publish 4

Anzeige des Ordners mit Location-ID 2 in der Plain-Ansicht in eZ Publish 5

Die hier vorgestellte Vorgehensweise, ein Modul zu migrieren, ist natürlich rein exemplarisch: Seine in eZ Publish 4 selbst entwickelte Module zu migrieren ist sicherlich naheliegender als das bei einem solch systemnahen Modul zu tun. Die gleiche Vorgehensweise eignet sich aber prinzipiell um beliebige Module schrittweise zu migrieren – Modul für Modul und Ansicht für Ansicht. Und selbst wenn final eine Migration von zugehörigen Legacy-Templates ohne Verwendung der Legacy-Template-Unterstützung von eZ Publish 5 beabsichtigt ist, empfiehlt sich in der Praxis, “natives” Twig zunächst nicht einzusetzen. So kann die “Uebersetzung” der Templates nach Fertigstellung der Controller-Action gleichermassen schrittweise (Template für Template) erfolgen. So ergibt sich eine Vorgehensweise wie im Diagramm unten ersichtlich.

Schrittweise Vorgehensweise für die Migration eines Moduls

Die umgekehrte Vorgehensweise, Templates direkt nach Twig zu migrieren und stattdessen Module als “Legacy-Bestandteile” in einem Controller einzubinden, scheitert an der Unterstützung hierfür – zumindest was eZ Publish 5 in seinem momentanen Pre-Alpha-Stadium betrifft. Interessant wäre diese Möglichkeit allemal. Generell ist dringend anzuraten, die Entwicklung von eZ Publish 5 ständig zu beobachten, da derzeit fast täglich Aenderungen in das Open-Source-Projekt einfliessen. So ist für das hier vorgestellte Einbinden von Legacy-Templates mittels als reine Wrapper agierende Twig-Templates bereits eine elegantere Alternativlösung angedacht (von Jérôme Vieilledent): Neben einem Komplett-Fallback auf eZ Publish 4 könnte es zukünftig eine weitere Fallback-Unterstützung geben, die sich lediglich auf die Templates aus eZ Publish 4 beschränkt und Twig als Template-Engine umgeht.

Wir fragen Sie: Welche Vorgehensweise, ein Modul zu migrieren, schwebt Ihnen vor? Und welche Module konkret würden Sie überhaupt migrieren?

0 Kommentare

Einen Kommentar abschicken

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