Die Krux eine gute Dateistruktur zu finden - Teil 1

von

Mit der Organisation von Dateien und Ordnern haben wir uns wirklich schwer getan. Schließlich entscheidet sie darüber, wie gut ein Nutzer sich im Theme zurechtfindet. Im ersten Teil geht es um eine mögliche Ordnerstruktur.

Über die Jahre haben wir unsere Workflow und damit auch die verbundene Datei- und Ordnerstruktur stetig weiterentwickelt. Heute ist ein Projekt bei uns in etwa so aufgebaut:

files (root folder)
|--content (aka the clients folder) |--theme |--assets (for extensions: modernizr, slider etc.) |--dist (for production files) |--css
|--fonts
|--img |--js |--src (for working files)
|--fonts |--img |--js |--scss

unsere Ordnerstruktur für Projekte

Für individuelle Websites und Kundenprojekte ist die Struktur wirklich ideal. Auch neue Team-Mitglieder finden sich schnell in der Datei- und Ordnerstruktur zurecht, kennen sie mitunter schon von anderen Projekten oder Frameworks.

Aber würde die Struktur auch für unser SOLO-Theme funktionieren?

Leider nicht. Denn im Gegensatz zu Projekten, bei denen wir ein Layout individuell auf die Bedürfnisse des Kunden zuschneiden, sind die Anforderungen an ein Theme deutlich größer. Ein Theme sollte

  • Varianten und Individualisierungen anbieten
  • erweiterbar sein
  • überflüssigen Code vermeiden
  • updatefähig bleiben

Diese 4 Punkte lassen sich allerdings nur schwer in Einklang bringen.

Als Theme-Ersteller müssen wir uns entscheiden:

Wollen wir, dass Theme-Nutzer ihre Individualisierungen in einer Datei custom.scss bündeln und die unsere Vorgaben überschreiben?

Oder wollen wir, dass Theme-Nutzer mit unseren Dateien und Strukturen arbeiten können und bestehende Vorgaben anpassen?

Während erstere Methode besser für spätere Theme-Updates geeignet ist, produziert letztere Methode gerade bei größeren Anpassungen deutlich weniger Code.

Am Ende haben wir uns für letztere Methode entschieden. Wir sind der Meinung, dass es auch bei der Verwendung und Anpassung von Themes wichtig ist, einen komfortablen Workflow anzubieten, in dem sich Entwickler leicht zurechtfinden können und der eine gute Performance der Website ermöglicht.

Um dennoch zumindest für Bugs eine einfache Updatemöglichkeit anzubieten, haben wir uns dazu entschlossen, das Theme in 2 Bereiche aufzuteilen.

  • Die Nutshell ist unser eigens für Contao entwickeltes Basis-Framework. Hier sind Basis-Formatierungen für Layoutbereiche, Typographie, Grid-Einstellungen, aber auch zum Beispiel die normalize.css von Nicolas Gallagher and Jonathan Neal enthalten.
  • Unter Themes findest du alle in der Demo gezeigten Varianten und kannst diese entweder so verwenden und anpassen oder dein eigenes Theme anlegen.

So könnte die Ordnerstruktur aussehen:

files (root folder)
|--content (aka the clients folder) |--theme |--assets (for extensions: modernizr, slider etc.)
|--dist (for production files) |--css
|--fonts
|--img |--js |--src
|--nutshell (our base-framework)
|--fonts
|--img
|--js
|--scss |--themes(for working files)
|--default
|--fonts
|--img
|--js
|--scss
|--yourtheme
|-- fonts

Was denkst du? Würdest du, bzw. der Theme-Nutzer mit solch einer Struktur zurechtkommen? Wie sieht für dich die perfekte Theme-Struktur aus? Schreib uns deine Meinung in die Kommentare oder per Mail.

Zurück

Kommentare

Einen Kommentar schreiben

Bitte rechnen Sie 9 plus 1.