Files

fs 25370a1a55 add composer-unused, comprehensive docs, and project restructure

- Add icanhazstring/composer-unused as dev dependency for dependency hygiene checks
- Add German documentation (docs/) covering architecture, conventions, workflows, and developer checklists
- Add API layer (ApiAuth, ApiBootstrap, ApiResponse), audit, scheduler, custom fields, and SSO services
- Add Microsoft OIDC SSO, API token management, and user lifecycle features
- Add swagger-ui vendor integration and OpenAPI spec
- Add production Docker setup and bin/ scripts
- Update composer dependencies, config, templates, and frontend assets throughout

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-02-22 15:27:35 +01:00

3.2 KiB

Raw Blame History

Frontend CSS

Letzte Aktualisierung: 2026-02-21

Ziel

Diese Seite beschreibt die kompakte Standardstruktur für CSS in diesem Projekt: klar, wartbar und ohne Seiteneffekte.

Struktur

/web/css/app-layers.css
- zentraler Entrypoint für Layer-Reihenfolge.
/web/css/base
- Variablen, Reset, Typografie, globale Tokens.
/web/css/layout
- Layout-Bausteine (Sidebar, Header, Main-Layout).
/web/css/components
- wiederverwendbare UI-Teile.
/web/css/pages
- seitenbezogene Styles mit engem Scope.
/web/css/vendor-overrides
- gezielte Overrides für externe Libraries.

Grundregeln

Neue Styles immer so lokal wie möglich einordnen:
- erst components/layout,
- pages nur bei echtem Seitenspezifikum.
Keine globalen Überschreibungen ohne Scope.
Bestehende CSS-Variablen bevorzugen, keine neuen Farbwerte „inline“ verteilen.
Vendor-Anpassungen ausschließlich in /web/css/vendor-overrides.

Entscheidungsmatrix: Neue Datei oder bestehende erweitern?

Situation	Empfehlung	Zielpfad
Bestehende Komponente bekommt kleine visuelle Erweiterung	Bestehende Datei erweitern	`/web/css/components/<bestehend>.css`
Neuer wiederverwendbarer UI-Baustein (mind. auf 2 Seiten)	Neue Komponentendatei anlegen	`/web/css/components/<neu>.css`
Änderung betrifft globales Layout (Sidebar, Header, Main)	Bestehende Layout-Datei erweitern	`/web/css/layout/<bestehend>.css`
Änderung ist nur für eine konkrete Seite relevant	Neue/ bestehende Seiten-Datei nutzen	`/web/css/pages/<seite>.css`
Externe Library muss übersteuert werden (Grid.js, Swagger UI)	Nur Vendor-Override ändern	`/web/css/vendor-overrides/<vendor>.css`
Neue Farben/Abstände/Typografie-Tokens werden benötigt	Erst Variablen in Base ergänzen, dann verwenden	`/web/css/base/*`

Kurzregel:

Bestehende Datei erweitern, wenn Scope und Verantwortung klar gleich bleiben.
Neue Datei anlegen, wenn ein neuer klarer Verantwortungsbereich entsteht.

Einbindung von Styles

Asset-Gruppen werden in /config/assets.php registriert.
Seiten laden bei Bedarf Gruppen über Buffer::set('style_groups', ...).

Beispiel (Action):

Buffer::set('style_groups', json_encode(['api-docs']));

Benennungs- und Scope-Konvention

Klassen konsistent mit app--Präfix halten, wenn es eigene Komponenten sind.
Status/Varianten über bestehende Attribute/Klassen abbilden (z. B. data-variant), nicht über zusätzliche Einmal-Klassen.
Selektoren kurz halten, keine unnötig tiefen Ketten.

Grid/Vendor

Grid.js-spezifische Anpassungen: /web/css/vendor-overrides/gridjs.css
Swagger UI-spezifische Anpassungen: /web/css/vendor-overrides/swagger-ui.css

Regel: Vendor-Overrides nur für Bibliotheks-Selektoren; projektspezifische UI-Stile in components/pages.

Checkliste vor Merge

Liegt die Datei im richtigen Ordner (components, layout, pages oder vendor-overrides)?
Ist die Asset-Gruppe in /config/assets.php korrekt?
Wird die Gruppe auf der Zielseite wirklich geladen (style_groups)?
Gibt es ungewollte Seiteneffekte auf anderen Seiten?
Sind bestehende Variablen/Konventionen eingehalten?

3.2 KiB Raw Blame History