Im zweiten Teil haben wir an einem hässlichen Beispiel gesehen, wie die einzelnen Bestandteile einer Webseite zusammenspielen. Im dritten Teil schauen wir uns an, wie man die Dateien bzw. die ganze Seite besser organisieren kann.
Ordnung ist das halbe Leben
Im letzten Beispiel hatten wir am Ende sechs Dateien, die alle in einem Verzeichnis lagen. Bei einem kleinen Projekt mit ein, zwei oder nur drei Seiten, kann man das durchaus machen. Oft erreichen solche Projekte aber einen Punkt, an dem sie wuchern. Es kommen immer mehr Dateien hinzu und es wird immer schwieriger, dies zu überblicken.
Es ist also durchaus ratsam, von Anfang an Ordnung zu halten. Wie diese Ordnung aussieht, hängt u. a. stark davon ab, was man eigentlich machen will und wie man programmiert.
Letztlich geht es um zwei Dinge:
- Wie lege ich die Verzeichnisstruktur an?
- Was kommt in welche Datei?
Verzeichnisse
In den meisten Fällen beginnt man damit, ein Verzeichnis mit dem Namen css und eines mit dem Namen js anzulegen. Hier landen die entsprechenden Dateien und beim Einbinden dieser Dateien müssen wir berücksichtigen, dass sich diese nicht mehr im Hauptverzeichnis sind. So wird bspw. aus
|
1 |
<link rel="stylesheet" type="text/css" href="style.css"> |
nun
|
1 |
<link rel="stylesheet" type="text/css" href="css/style.css"> |
Irgendwann soll die Seite Grafiken beinhalten. Das Verzeichnis hierfür wird meistens gfx, img oder allgemein media genannt.
Vor allem, wenn man PHP verwendet, taucht ein Verzeichnis mit dem Namen includes auf. Das ist, mehr oder weniger, dieser Zeile aus dem letzten Teil geschuldet:
|
1 |
<?php require_once('header.php');?> |
Früher schrieb man vor allem include statt require_once. Die Hintergründe sind an dieser Stelle unwichtig, aber weil man alle Dateien per include holte, legte man diese Dateien natürlich in den includes-Ordner. Hier befinden sich i. d. R. alle Dateien, die von anderen Dateien gebraucht werden.
Allerdings wird das nicht 100 % konsequent gelebt. Beim Beispiel von zweiten Teil würden wir die drei Dateien, also header.php, navigation.php und footer.php nicht in einen solchen Ordner werfen. Es geht viel mehr um Dateien, die im Hintergrund arbeiten und von denen der Seitenbesucher nicht wirklich etwas mitbekommt und die nicht zwingend etwas mit dem Layout zu tun haben. Ein Klassiker ist die config.php, teilweise auch config.inc.php genannt.
Weitere Verzeichnisse könnten lauten:
- admin, backend oder vergl., falls es einen administrativen Bereich gibt
- downloads, für die Dateien, die man dem User anbieten kann
- uploads, falls Seitenbesucher Dateien hochladen dürfen
- language für eigene Sprachdateien
Diese Struktur wird vor allem bei kleineren und mittleren Webseiten angewendet. Das kann eine HP, eine Highscoreliste, kleine Tools oder auch ein kleines CMS sein. Bei großen CMS wie WordPress oder Joomla sieht die Struktur noch einmal anders aus.
WordPress bspw. hat nur drei Verzeichnisse:
- wp-admin
- wp-content
- wp-includes
Die Entwickler von WordPress halten sich vorwiegend in den Verzeichnissen wp-admin und wp-includes auf. Entwickler von PlugIns und Templates sind vorwiegend im Verzeichnis wp-content zuhause. Der Endanwender bekommt davon im besten Fall überhaupt nichts mit. Auch das sind Aspekte, die man beim Softwaredesign berücksichtigen muss.
Dateien
Als Anfänger mag man sich fragen, was es bei den Dateien zu beachten gibt? Schließlich haben wir nun eine ordentliche Verzeichnisstruktur und in die Verzeichnisse speichern wir unsere Dateien ab. Ja. Und nein.
Webseiten sollten in jeder Hinsicht effizient sein. Eine Sicht ist die des Seitenbesuchers. Die Ladezeiten sollten möglichst gering sein. Eine andere Sicht ist der Server. Dieser sollte möglichst wenig belastet werden. Und noch eine weitere Sicht ist die des Programmierers. Es sollte alles möglichst logisch und übersichtlich sein. Von Aspekten der Sicherheit haben wir noch gar nicht gesprochen. Um das Thema zu verstehen, möchte ich zwei Beispiele anführen.
Auch bei einer Umfangreichen Seite können wir alles in eine CSS und in eine JS Datei stopfen. Das Problem ist: Es ist sehr wahrscheinlich, dass davon nicht alles auf jeder Seite gebraucht wird. Der Benutzer muss das aber jedes Mal herunterladen. Effizienter ist es, den Inhalt in mehrere Dateien zu unterteilen und diese nur dann zu laden, wenn sie tatsächlich gebraucht wird. So kann es sein, dass man nicht auf jeder Seite das Design für Tabellen braucht. Oder das Template für ein Forum. Also gibt es hierfür eigene Dateien und diese werden erst geladen, wenn es eine Verwendung für sie gibt.
Übrigens ist das auch ein Problem von HTML5-Exportern bei Entwicklungsumgebungen, auch für Spiele. Selbst wenn man nur einen kleinen Sprite zeigen will, sind die JS Dateien ein bis mehrere Megabyte groß, weil die Entwicklungsumgebung alles hinein stopft, was man gebrauchen könnte. Das gilt allerdings nicht nur für den HTML5-Export.
Ein zweites Beispiel sind PHP Dateien. In PHP kann man prozedural und objektorientiert programmieren. Man kann das sogar mischen. Bei der objektorientierten Programmierung (OOP) arbeitet man mit Klassen, bei der prozeduralen Programmierung mit Funktionen (vereinfacht gesagt). Um nicht jedes Mal alles zu laden, wird es meist so unterteilt, dass man in der OOP für jede Klasse eine Datei anlegt. Bei Funktionen gruppiert man diese gerne nach Aufgaben. Das heißt, dass mehrere Funktionen, die aber das gleiche Themengebiet behandeln, in eine Datei kommen.
Das ist allerdings kein Gesetz. Es gibt auch Programme, die alles in eine Datei stopfen. Anschließend darf man sich durch viele tausend Zeilen Code arbeiten, was in etwa so viel Spaß macht wie Grashalme zu zählen.
Fazit
Wir sehen, dass es durchaus sinnvoll ist, von Anfang an alles sauber zu trennen und zu unterteilen. Schließlich wollen wir den Überblick nicht verlieren und auch keinen doppelten Code produzieren. Allerdings ist es auch so, dass man die Effizienz erst lernen muss. Das braucht viele Jahre Erfahrung. Entwickler, die nahezu täglich Code schreiben, staunen selbst oft darüber, wie ineffizient ihr alter Code eigentlich ist. Und bei „alt” reden wir von ein bis drei Jahren.
Ausblick
Ab dem nächsten Teil steigen wir in JavaScript ein. Über mehrere Teile hinweg versuche ich, ein Grundverständnis für das Thema zu vermitteln.
Überblick Webdev-Serie
Webentwicklung Grundkurs Teil 1 – Einstieg
Webentwicklung Grundkurs Teil 2 – Aufbau von Webseiten
Webentwicklung Grundkurs Teil 3 – Datei- und Ordnerstrukturen
Webentwicklung Grundkurs Teil 4 – Einstieg in JavaScript
Webentwicklung Grundkurs Teil 5 – Datenverarbeitung und Formulare mit JavaScript
Überblick Interviews
Interview mit Magnus Reiß – Webgamers
Interview mit Wolfgang Scheidle – Tischtennis Manager
Interview mit Warg – Drifting Souls II
