Dieser Artikel stellt den Einsatz von Sharp, einem Open Source Content Management Framework, an einem Beispiel innerhalb eines Laravel-Projekts vor.

Um es gleich vorwegzunehmen: Content Management ist schwierig. Für ein typisches Webprojekt gilt das für beide Seiten: Es kann schwierig sein, als Entwickler ein angepasstes Tool zu erstellen, und es ist manchmal mühsam, es als Content Manager zu verwenden. Ich denke, das ist der Grund, warum WordPress und kleinere Projekte, die auf der gleichen Idee basieren, sehr beliebt waren und sind: Es ist für einen Entwickler relativ einfach, sie an jede Art von Inhalt anzupassen, und der Kunde kennt das Tool vielleicht schon und fühlt sich mit der Oberfläche wohl. Aber diese Lösungen haben auch viele Nachteile: ein eingeschränktes Datenmodell, Schwierigkeiten bei der Wartung und Aktualisierung, die Notwendigkeit, die Benutzeroberfläche an die Domaindaten anzupassen und vieles mehr.

Sharps kurze Vorgeschichte

Wie viele essenzielle, aber schwer zu lösende Themen wird auch Content Management von vielen Paketen, SaaS-Projekten und Tools adressiert. Als ich auf Laravel traf (es war in seinen frühen Tagen, um Version 3), war das Feld ziemlich leer, und ich fühlte die Notwendigkeit, etwas zu bauen. Die Idee zu Sharp war geboren, und es war anfangs zugegebenermaßen sehr chaotisch. Ich habe versucht, etwas zu entwickeln, das sowohl für reguläre Websites als auch für Verwaltungsanwendungen (CRM, Ticketsysteme etc.) geeignet ist, und es hat irgendwie funktioniert, aber die Wartung war mühsam, und ebenso die Anpassung an neue Laravel-Versionen. Ich habe aber nicht aufgegeben: nach massenhaften Refactorings und Rewritings und mit der großartigen Hilfe von anderen Entwicklern haben wir es geschafft, 2017 ein anständiges Produkt zu veröffentlichen – das war Sharp 4, die aktuelle Version ist 7. Wir hatten gleich von Beginn an vier grundlegende, aber entscheidende Regeln im Kopf:

• Der öffentliche Bereich der Website sollte keine Kenntnis von Sharp haben: Das Tool ist ein Teil des Systems, nicht dessen Mittelpunkt. In der Tat sollte das Entfernen des Tools keine Auswirkungen auf das Projekt haben.

• Content-Administratoren sollen mit ihren Daten und ihrer Terminologie arbeiten, nicht mit CMS-Begriffen.

• Die Entwickler sollen nicht an der Frontend-Entwicklung für das CMS arbeiten müssen.

• Das CMS soll keine Erwartungen an die Persistenzschicht stellen.

Seit der ersten Version von Sharp hat sich im Bereich Content Management mit Laravel viel getan: etwa das Aufkommen großartiger kostenpflichtiger Produkte (Laravel Nova [1], Statamic [2], October CMS [3]) oder der Aufstieg von headless CMS [4]. Aber Sharp ist für uns und andere immer noch eine sehr relevante Wahl, da es in seinen Grundregeln stabil und sehr flexibel sowie für einen technisch nicht versierten Benutzer relativ einfach zu bedienen ist, es Entwicklern erlaubt, schnell komplexe und testbare Funktionen zu erstellen, und außerdem Open Source und kostenlos ist.

In unserem Webunternehmen verwenden wir es für fast alle unsere Projekte: Websites, mobile Anwendungen, SPAs etc. Hier ein paar Beispiele, die die Vielfalt der Verwendungsmöglichkeiten illustrieren:

• Im Bereich E-Commerce haben wir in Sharp für einen Kunden ein vollständiges Produkt- und Auftragsmanagement entwickelt, das partielle Änderungen und Statusaktualisierungen ermöglicht, eine vollständige Historie beibehält, mit externen APIs synchronisiert wird, Verkaufs- und To-do-Dashboards präsentiert, den eigentlichen Inhalt der Website verwaltet und mehr.

• Wir mussten Websites entwickeln, die sich wirklich auf das Frontend konzentrieren, mit verschiedenen Arten von Inhalten (Bilder, Videos, externe Einbettungen, Rich-Texte). Für diese Art von Projekten ist das neue Editorfeld von Sharp 7 ein Segen.

• Bei mobilen Anwendungen, die ein API benötigen, wird Sharp eingesetzt, um den Inhalt zu verwalten, manchmal auch, um die Verbindungen zu verfolgen oder um API-Schlüssel zu verwalten.

• Wir verwenden Sharp auch als Nebenwerkzeug, um bei bestehenden Apps, die bereits einen weniger flexiblen Adminbereich haben, schnell eine Möglichkeit zur Verwaltung von Benutzern, Berechtigungen oder Konfigurationen hinzuzufügen.

Um Sharp zu präsentieren, ist es meiner Meinung nach am besten, ein Beispiel durchzugehen; und selbst wenn wir dabei viele Funktionen übersehen und ignorieren, ist es vielleicht hilfreicher, Code zu betrachten als eine Funktionsliste zu lesen.

Eintauchen in Sharp

Wenn Sharp im Laravel-Projekt installiert wird (als Composer-Abhängigkeit), enthält es lediglich eine neue /sharp-Route mit einem Anmeldeformular. Alles nach diesem Log-in muss konfiguriert und entwickelt werden, wobei das API von Sharp genutzt wird.

Hier ist unser Szenario: Wir sollen auf einer Website die Produkte eines lokalen Geschäfts präsentieren. Die Produktliste stammt aus einem externen Feed, der von einer Warenwirtschaftssoftware bereitgestellt wird. Wir müssen im Verwaltungsbereich der Website die detaillierte Produktliste anzeigen (Artikelnummer, Preis etc.). Zu diesem Zweck werden wir eine ProductEntity deklarieren (in Sharp ist eine Entity ein verwaltbares Ding; typischerweise ist es ein Model, aber es kann alles sein) und eine ProductList entwickeln.

class ProductEntity extends \Code16\Sharp\Utils\Entities\SharpEntity
{
  protected ?string $list = ProductList::class;
}

Der ProductList-Code könnte wie in Listing 1 geschrieben werden. Schauen wir uns das in einer Zusammenfassung an:

• buildListField() und buildListLayout() enthalten die Struktur und die Art der Darstellung; in diesem Fall handelt es sich um eine Liste, daher sind Felder Spalten. Wir deklarieren drei, zwei davon sind sortierbar.

• getListData() macht besonders viel Arbeit: Diese Methode muss eine Arrayversion jedes Produkts in einem globalen Array...