Nachdem im letzten Artikel gezeigt wurde, mit welchen Mitteln sich in GitHub Actions Projekte auf Basis von PHP verarbeiten lassen, schauen wir nun auch einmal kurz in die Java-Welt.
Werkzeuge für das Build-Management In Java ist es gang und gebe, die Builds mit spezifischen Tools zu beschreiben, hier sind als gängigste Beispiele Maven, Gradle oder auch Ant zu nennen. Das ist insoweit hilfreich, als dass viele Abhängigkeiten darüber verwaltet werden.
Eine Aktion zur PHP-Einrichtung Für die wichtigsten Punkte, die notwendig sind, um ein auf PHP basierendes Projekt zu testen, gibt es die Action setup-php. Diese bietet unter anderem folgende Möglichkeiten:
unterschiedliche PHP-Versionen verwenden PHP-Extensions einrichten PHP-Konfigurationen vornehmen zusätzliche, häufig verwendete Tools installieren Diese Aktion sollte für allgemeine Anwendungen keine Wünsche offen lassen. Wir verwenden diese Aktion seit einigen Monaten in mehreren Repositories ohne jegliche Probleme.
Weitergehende Möglichkeiten Auch Matrix-Builds sind möglich: hiermit lässt sich ein Workflow für mehrere Betriebssysteme und/oder PHP-Versionen ausführen.
Nach der allgemeinen Einführung in GitHub Actions kommen wir nun zu dem ersten Anwendungsfall, der in vielen Projekten angewendet werden kann. Fast jedes Softwareprojekt bedient sich heutzutage zusätzlicher Drittkomponenten. Diese müssen regelmäßig geprüft und auf Stand gehalten werden, um sowohl Fehlerkorrekturen als auch neue Funktionen zu erhalten. In den meisten Programmiersprachen und Umgebungen kommen Paketmanager zum Einsatz, mit denen diese Abhängigkeiten verwaltet und gepflegt werden. Das ist eine geeignete Voraussetzung dafür, die Updates zu automatisieren.
Mit GitHub Actions ist es möglich, beliebige Workflows in einem GitHub Repository zu definieren und dort auch automatisch ausführen zu lassen. Das können Builds und Tests zur kontinuierlichen Integration sein, aber auch völlig unabhängige Prozesse, zum Beispiel zur regelmäßigen Prüfung bestimmter Anforderungen.
In den letzten Wochen und Monaten haben wir mehrere Dutzend Workflows mit GitHub Actions abgebildet und entsprechende Erfahrungen gesammelt. Im Rahmen einer kleinen Artikelserie werden wir einige der vielfältigen Möglichkeiten vorstellen, die sich mit GitHub Actions auftun.
Schon seit einiger Zeit werden im GitHub-Repository des Zikula Core die Dinge dokumentiert, die zusätzlich zu den Handbüchern von Symfony, Doctrine, Twig, Bootstrap usw. zu beachten sind. Nun wurde die Struktur dieser Dokumente jedoch überarbeitet und in eine Gesamtsicht gekleidet.
Themenorientiert Frühere Ansätze von Handbüchern und Doku-Sammlungen haben oft versucht, unterschiedliche Bereiche für Entwickler und Administratoren aufzubauen. Dies hatten wir wieder versucht, sind dann aber zu der Erkenntnis gelangt, dass es zu viele Überschneidungen gibt und das Ganze vor allem unübersichtlich wird.
Nachdem wir bereits in einigen Artikeln zu Zikula 3 die Änderungen unter der Haube, umfangreiche Modernisierungen, Möglichkeiten für dynamische Formulare und Neuerungen rund um Übersetzungen vorgestellt hatten, sollen nun einige weitere der neuen Features und Änderungen vorgestellt werden.
Module + Themes = Extensions Die Verwaltung von Modulen und Themes läuft nun unter einem gemeinsamen Dach: Extensions.
Hintergrund ist unter anderem, dass Themes ebenso wie Module eigenständige Symfony-Bundles sind und mehr als nur Layout können.
Nachdem zwischen den Jahren der komplette Unterbau von Zikula 3 auf Stand gebracht worden ist, hat sich der nächste Sprint dem Übersetzungssystem gewidmet. In diesem Beitrag wird kurz dargestellt, welche neuen Funktionen eingebracht worden sind:
Es gibt eine verbesserte Unterstützung für Regionen und Sprachvarianten (z. B. de_DE und de_CH neben de). Die automatische Erkennung zusätzlich vorhandener Sprachpakete wurde verbessert. Die Konfiguration für die Übersetzung von Modulen und Themes wird automatisch auf Stand gehalten.
Im Rahmen des letzten Sprints wurde der Unterbau von Zikula 3 auf den neuesten technischen Stand gebracht. Im Folgenden wird kurz zusammengefasst, was hierbei genau passiert ist.
Twig 3 Als erstes sollte die Template-Engine Twig auf die Version 3 gebracht werden. Dies versprach anfangs eine sehr übersichtliche Sache zu werden. Allerdings gab es dann doch noch einige weitere Aspekte zu beachten:
Da die templating-Komponente in Symfony 5 entfernt wird, müssen Pfade zu Templates nun der Namespace-Notation folgen.
Der folgende Tipp hilft dabei, den Code-Umfang häufiger Abfragen in Twig-Templates zu reduzieren. Dies verbessert die Lesbarkeit enorm und hilft dabei, die Logik in den Templates intuitiver zu formulieren. Diese Abkürzung kommt komplett ohne zusätzliche Funktionen und Filter aus.
Oft möchte man prüfen, ob eine Variable im Template existiert und einen gültigen Wert enthält. In dem Fall soll etwas mit der Variable getan werden, typischerweise erfolgt eine Ausgabe des Wertes. Ganz explizit formuliert sieht so eine Abfrage in etwa wie folgt aus:
Seit kurzem haben neue Funktionen in die Template-Engine Twig Einzug gehalten. Diese verändern die Art und Weise, wie mit mehrwertigen Daten umgegangen wird, fundamental. Aus diesem Grund soll dieser Artikel beleuchten, wie man mit den neuen Möglichkeiten umgehen kann.
Was heißt deklarativ? Bei “filter, map und reduce” handelt es sich um ein Muster (Pattern) aus der funktionalen Programmierung. Es erlaubt die Veränderung von Sequenzen (Listen, Arrays, Vektoren, usw.) mittels mehrerer Operationen und Manipulationen, an deren Ende ein Ergebnis steht, welches entweder ausgegeben oder weiter verwendet werden kann.
