Projektvorstellung: eine eigene Team-Seite mit Kategorie-Filter, Modul- und Seitenkonzept
Projektvorstellung: eine eigene Team-Seite mit Kategorie-Filter, Modul- und Seitenkonzept
~7 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Ab jetzt bauen wir, über die restlichen Kapitel dieses Blocks, ein durchgehendes Beispielprojekt: eine eigene Storefront-Seite mit einer Team-Übersicht, die sich per Kategorie-Buttons live filtern lässt - komplett ohne Page-Reload. Jedes der folgenden Kapitel baut direkt auf dem vorherigen auf, bis am Ende (Kapitel 22) eine vollständig funktionierende, CSP-konforme Seite steht.
Die Seite, die wir bauen
Ziel ist eine Seite unter der URL /team, die alle Mitarbeiter des fiktiven mironsoft-Teams als Karten-Grid anzeigt - Name, Rolle und Kategorie (z. B. "Entwicklung", "Design", "Support"). Über Kategorie-Buttons oberhalb des Grids lässt sich die Anzeige live filtern, ganz ohne dass die Seite neu lädt.
Das Modul: Mironsoft_TeamPage
Die Seite entsteht als eigenständiges Modul Mironsoft_TeamPage unter app/code/Mironsoft/TeamPage/ - nicht als Theme-Override, weil es sich um komplett neue Funktionalität handelt, keine Anpassung von etwas Bestehendem (die Faustregel aus Kapitel 4: eigene neue Module bringen ihre Templates selbst mit).
Zielstruktur des Mironsoft_TeamPage-Moduls (wird über die Kapitel 18-22 gefüllt)
app/code/Mironsoft/TeamPage/
├── registration.php
├── etc/
│ ├── module.xml
│ └── frontend/
│ └── routes.xml
├── Controller/
│ └── Index/
│ └── Index.php
├── ViewModel/
│ └── TeamMembers.php
└── view/
└── frontend/
├── layout/
│ └── team_index_index.xml
└── templates/
└── team/
└── index.phtmlRoute und URL
Der Front-Name der Route ist team, der Controller heißt Index/Index - zusammen ergibt das die URL /team (die Standard-Action index/index muss in der URL nicht ausgeschrieben werden). Kapitel 18 zeigt routes.xml und den Controller im Detail.
Die Daten: Team-Mitglieder und Kategorien
Für dieses Tutorial reicht eine einfache, im ViewModel fest hinterlegte Liste - kein eigenes Datenbank-Schema, kein Repository-Pattern mit echter Persistenz. Das hält den Fokus auf Hyvä-spezifischen Konzepten (Layout, ViewModel, Template, Alpine, CSP) statt auf Datenmodellierung. Geplante Kategorien: Alle, Entwicklung, Design und Support.
Tipp: In einem echten Projekt würde man die Team-Daten wahrscheinlich über ein eigenes CMS-Modul, eine Datenbank-Tabelle oder ein Repository pflegen - das ViewModel würde dann intern ein Repository injizieren, statt die Daten direkt zu enthalten. Die Struktur der Templates und der Alpine-Logik in diesem Tutorial bleibt davon aber unberührt: Das ViewModel-Interface nach außen (getTeamMembers(), getCategories()) wäre identisch.
Was in den nächsten Kapiteln passiert
- Kapitel 18: Layout-XML, Route und Controller anlegen - die Seite ist erstmals unter
/teamerreichbar (noch ohne Inhalt). - Kapitel 19: das ViewModel mit den Team-Daten schreiben.
- Kapitel 20: das Template mit Tailwind gestalten - statisches Karten-Grid.
- Kapitel 21: Alpine-Filterlogik integrieren - Kategorie-Buttons filtern live.
- Kapitel 22: das Inline-Skript CSP-konform registrieren und die gesamte Seite testen.