logo

Extra Block Types (EBT) - Neue Erfahrung im Layout Builder❗

Extra Block Types (EBT) - gestylte, anpassbare Blocktypen: Diashows, Registerkarten, Karten, Akkordeons und viele andere. Eingebaute Einstellungen für Hintergrund, DOM Box, Javascript Plugins. Erleben Sie die Zukunft der Layouterstellung schon heute.

Demo EBT-Module EBT-Module herunterladen

❗Extra Absatztypen (EPT) - Erfahrung mit neuen Absätzen

Extra Paragraph Types (EPT) - analoger, auf Absätzen basierender Satz von Modulen.

Demo EPT-Module EPT-Module herunterladen

Scroll

1.3. Aufbau unseres PHP-Frameworks

26/05/2025, by Ivan

Es gibt viele verschiedene Wege, ein Framework zu konstruieren. Manche bevorzugen sehr komplexe Frameworks, andere sehr einfache. In unseren Artikeln wollen wir ein einfaches und leicht verständliches Framework schnell zusammenbauen.

Unsere Artikel helfen Ihnen dabei, ein eigenes Framework zu entwickeln, das sich von dem unterscheidet, das wir für einen Online-Shop benötigen. Sie können später leicht weitere Teile zum Framework hinzufügen, um etwas Größeres zu erstellen. Das Hauptziel der Artikelserie ist es, zu lernen, wie man sein eigenes Framework für beliebige CMS erstellt.

Designmuster (Patterns)

Für die Entwicklung von Frameworks werden verschiedene Designmuster verwendet. Ein Pattern ist eine bewährte Lösung oder Praxis, die allgemeine Entwicklungsprobleme löst. Wir werden folgende Patterns nutzen:

  • Model-View-Controller (MVC)
  • Registry
  • Singleton

Model-View-Controller (MVC)

MVC bildet die Grundlage unseres Frameworks. Es bietet eine Lösung, um Benutzeroberfläche und Logik zu trennen. Die View (Benutzeroberfläche) arbeitet mit den Datenmodellen (Model) über die Controller zusammen, die die Geschäftslogik zur Steuerung der Daten in den Modellen enthalten.

Beispielsweise, wenn ein Benutzer in der View auf „In den Warenkorb“ klickt, verarbeitet der Controller diese Anfrage, kommuniziert mit dem Warenkorbmodell und fügt den Artikel hinzu. Das Modell liefert dem Controller die aktuelle Anzahl der Artikel im Warenkorb zurück, und die View zeigt den aktualisierten Warenkorb an.

MVC

Wir verwenden unser eigenes Framework und erweitern es basierend auf MVC. Die Daten liegen in Modellen, die die Tabellen in der Datenbank abbilden (Felder der Modelle entsprechen den Tabellenfeldern). Wir erweitern das MVC-Diagramm um das Ergebnis, das im Browser angezeigt wird (View).

MVC scheme

Registry

Die Registry ermöglicht das Speichern einer Sammlung von Objekten unseres Frameworks. Sie ist notwendig, weil das MVC-Pattern Abstraktion erfordert. Jeder Controller und jedes Modell (z. B. Produkt, Warenkorb, Seite) benötigt Funktionen wie:

  • Datenbankabfragen
  • Prüfung, ob der Benutzer angemeldet ist
  • Übergabe von Daten an die View (Template-Verwaltung)
  • Versand von E-Mails, z. B. bei einer Bestellung
  • Interaktion mit dem Dateisystem, z. B. Hochladen von Produktfotos

Die meisten Systeme und Frameworks implementieren diese Funktionen in Objekten, die wir ebenfalls erstellen. Die Registry speichert diese Objekte zentral. Sie kann von überall im Framework aufgerufen werden und stellt Zugriff auf deren Funktionen bereit. Hier ein beispielhaftes Diagramm der Registry:

MVC

Das Framework interagiert direkt mit der Registry, die wiederum Zugriff auf andere Objekte ermöglicht. Innerhalb der Registry können Objekte auch untereinander kommunizieren, z. B. Template-Manager mit Dateimanager, E-Mail-Sender mit E-Mail-Vorlagen usw.

Singleton

Das Pattern „Singleton“ wird im Russischen manchmal als „Единичный класс“ bezeichnet, obwohl oft der englische Begriff genutzt wird. Wir verwenden hier den Begriff „Единичный класс“.

Singleton ist eines der einfachsten Muster: Es garantiert, dass nur eine Instanz einer Klasse existiert. Dies ist wichtig, wenn nur ein Objekt benötigt wird, das überall im Programm zugänglich sein soll, also global verfügbar ist.

Singletons werden z. B. für die Konfiguration einer Datenbankverbindung verwendet, damit alle Objekte dieselbe Verbindung nutzen können.

Gesamtstruktur

Der nächste Schritt bei der Entwicklung unseres Frameworks ist die Strukturplanung. Wir müssen Verzeichnisse anlegen für:

  • Modelle
  • Views (um verschiedene Site-Stile in separaten Ordnern zu verwalten)
  • Controller (jeder Controller in eigenem Ordner, einfach erweiterbar)
  • Admin-Controller (für CMS-Funktionalität, Moderatoren und Administratoren)
  • Registry
  • Registry-Objekte
  • Uploads
  • Third-Party Libraries
  • Sonstiger Code

Die Ordnerstruktur unseres Frameworks sieht demnach so aus (wir verwenden englische Namen, wie in PHP üblich):

  • Models
  • Views
    • ViewA
    • Templates
    • Images
    • JavaScript
  • Controllers
    • ControllerA
      • ControllerA
      • ControllerAAdmin
  • Registry
    • Objects
    • Datenbank-Objekte
  • Assets
  • Uploads
    • Wird erweitert, wenn wir Produkte und Bilder hinzufügen
  • Libraries
  • Miscellaneous