Laravel - das einfachste Tutorial der Welt - Teil 1
Laravel ist der heiße Scheiss in der PHP-Webentwicklung. Man kann mit diesem MVC-Framework innerhalb von Stunden eine komplette, hübsche, sichere, funktionale Website aufsetzen und muss sich nicht mehr um Logins, SQL, Javascript-Minimierung und den ganzen anderen Kleinkram bei der Webentwicklung kümmern. Laravel als Framework nimmt einem jede Menge unangenehmer Arbeiten ab. Dieses kleine Tutorial zeigt dir, wie du in Laravel einen einfachen Terminkalender erstellst.
Vorraussetzungen
Laravel setzt ein paar Dinge voraus. Du solltest bereits PHP in einer aktuellen Version (7.x) installiert haben. Außerdem benötigst du den Composer, sowie auch nodejs. Falls Du mit MySQL/MariaDB arbeiten möchtest, brauchst du einen MariaDB-Datenbankserver. Du kannst auch eine SQLite-Datenbank nutzen, die SQLite-Erweiterung von PHP muss dafür installiert sein.
Projekt aufsetzen
Öffne ein Terminal und wechsel in das Verzeichnis, wo du normalerweise deine Webprojekte ablegst. Unter Windows wäre das vielleicht c:\xampp\htdocs und bei Linux vielleicht /var/www/htdocs/. Ich entwickele gerne in meinem Heimatverzeichnis ~/www/, aber das muss jeder selbst wissen.
Sobald Du in deinem Projektverzeichnis bist, kannst Du dein Laravel-Projekt mit folgendem Befehl erstellen:
composer create-project laravel/laravel terminkalender
composer erstellt das verzeichnis terminkalender und zieht laravel und die benötigten Abhängigkeiten.
Du kannst dir dein Projekt jetzt bereits anschauen. Wechsel in das Verzeichnis terminkalender und starte den Laravel-Webserver mit dem Befehl php artisan serve
Wenn Du jetzt im Browser die Adresse http://localhost:8000 aufrufst, siehst du diese Website:
Datenbank konfigurieren
Bei der Datenbank fangen wir ganz einfach an. Wir wollen einfach nur eine MariaDB-Datenbank namens terminkalender haben. Unser MariaDB-Server läuft und wir erstellen jetzt in phpmyadmin oder in der mysql-shell diese Datenbank: create database terminkalender
Damit Laravel weiß, dass es sich mit dem lokalen Datenbankserver verbinden soll und die Datenbank terminkalender benutzen soll, müssen wir die Konfiguration unserer Anwendung öffnen. Laravel speichert die grundsätzlichen Konfigurationsdaten in einer Datei namens .env, die wir nun öffnen.
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=terminkalender
DB_USERNAME=meinBenutzerName
DB_PASSWORD=meinSuperPasswort
Ziemlich simpel, oder? Falls deine .env nicht existiert, kannst du gerne die .env.example nach .env kopieren. Allerdings musst du dann auch einen Applikations-Schlüssel mit php artisan key:generate erstellen.
Unser erster Controller
Wir gehen wieder in die Shell und schreiben folgende Befehlszeile
php artisan make:controller CalendarController --resource
Artisan hat nun app\Http\Controllers\CalendarController.php erstellt. Eine ziemlich große PHP-Klasse, die aus sieben Methoden besteht:
- index
- create
- destroy
- edit
- store
- update
- show
Der --resource-Parameter sorgt dafür, dass der Controller schon mit Methoden gefüllt wird. Hier hat das Laravel-Team ein sogenanntes Scaffolding für die üblichen Funktionen, die man so braucht, erstellt. Die Aufgabe von Controllern ist in der Regel die Ein- und Ausgabe von Daten. Unser Controller soll bei den oben genannten Methoden bestimmte Dinge tun.
Ohne --resource würden alle Methoden fehlen und man müsste sich die selbst erstellen. Oft braucht man ja auch nicht alle Methoden. Ich bin aber stinkend faul, daher lass ich das Framework meinen Code schreiben.
Index
Die Index-Methode soll unsere Termine anzeigen. Alle.
Create
Create soll uns ein Formular anzeigen, in dem wir einen Termin hinterlegen können
destroy
Destroy soll unseren Termin löschen.
edit
Einen vorhandenen Termin in einem Formular anhigen
store
Den neuen Termin speichern.
update
Den vorhandenen Termin aktualisieren
show
einen bestimmten Termin anzeigen lassen.
Unser erster Aufruf
Wir wollen, dass beim Aufruf von http://localhost:8000/termine unser Programm alle Termine darstellt. Laravel arbeitet zur Verarbeitung von URLs mit sogenannten Routen. Diese Routen legen fest, was unsere Applikation bei bestimmten URLs eigentlich machen soll. Wenn ich den Link einfach so aufrufe, kommt eine Fehlerseite. Laravel sagt: Route kenn ich nicht, also Fehler.
Routen bei Laravel
Wir öffnen die Datei /routes/web.php. Dort steht aktuell nur folgendes drin:
Route::get('/', function () {
return view('welcome');
});
Ignorieren wir erst einmal. Wir wollen, dass unser Controller geladen wird und dass die Index-Methode aufgerufen wird. Wir teilen dem Framework also unseren förmlichen Wunsch mit, das bitte auch so zu machen.
Route::get('/termine', 'CalendarController@index');
/termine ist der Pfad und nach dem Komma steht, welche Klasse Laravel mit welcher Methode aufrufen soll. Wenn wir die URL http://localhost:8000/termine jetzt aufrufen, haben wir eine weiße Seite. Da die Methode im Moment noch nichts macht, ist unser Skript total gut und fehlerlos. Aber wir wollen, dass er zumindest irgendwas mal ausgibt.
Wir spielen das mal durch: Wir öffnen unseren CalendarController noch einmal und schreiben die index-Methode mal um:
class CalendarController extends Controller
{
/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/
public function index()
{
echo 'Hallo';
}
Nun rufen wir ein weiteres mal http://localhost:8000/termine auf und sehen ein schönes, einfaches Hallo auf unserer Seite.
Öffnen wir nun noch mal die web.php und schreiben folgende Zeile dazu
Route::get('/termine/wurstbrot', 'CalendarController@create');
Ausserdrem schreiben wir nun noch die create()-Methode im Controller um:
public function create()
{
echo 'Ciao';
}
Du siehst nun bei einem Aufruf von http://localhost:8000/termine/wurstbrot eine weiße Seite, auf der Ciao steht.
Fazit: Es ist also egal, wie du deine URLs nennst, du musst lediglich ein entsprechendes Skript oder einen Controller dahinter schreiben, sodass Laravel weiß, was es wann machen soll. Unbekannte Routen führen erstmal immer zu Fehlern.
Views
Öffne noch einmal die web.php- die erste Route legt fest, dass bei einem Aufruf von / ein view namens welcome zurück gegeben wird. Was zur Hölle ist das schon wieder.
Views sind der Bereich deiner Website, die deine Kunden sehen. Ein View ist eine Startseite und ein View ist eine Unterseite und so weiter und sofort. Views speichert Laravel normalerweise im Ordner /resources/views und wenn du dort nachschaust, findest Du eine Datei namens welcome.blade.php.
In web.php steht also drin, dass welcome zurück gegeben werden soll. Laravel hängt “blade.php” selbst hinten dran. Wenn du also diese Zeile änderst und so umbaust:
Route::get('/', function () {
return view('calendar');
});
Ein Aufruf von http://localhost:8000/ wird nun eine Fehlerseite ausgeben. Laravel kennt die Datei calendar.blade.php nicht.
Erstellen wir einen View
Da es die Datei calendar.blade.php noch nicht gibt, erstellen wir diese Datei im Ordner /resources/views/
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Calendar</title>
</head>
<body>
<h1>Kalenderübersicht</h1>
<div>
<h2>Anstehende Termine für Heute</h2>
<ul>
<li>1.1.2019 - Neujahr feiern</li>
<li>5.2.2019 - Geburtstag feiern</li>
</ul>
</div>
</body>
</html>
Wenn wir die Seite nun aktualisieren, sehen wir eine Website, die in etwa so aussieht:
An dieser Stelle können Webdesigner loslegen und mit CSS, HTML und Bildern schon einmal einen sehr hübschen View zusammen basteln. In den Agenturen, in denen ich bereits gearbeitet habe, wurde dem Kunden zuerst mal ein Clickdummy gebaut und der Kunde konnte sehen, wie sich die Seite nachher verhält.
Wir fangen erst mal einfach an und legen CSS-Daten im Ordner public\css ab. Unsere Bilder finden wir in public\images\und so weiter. Angenommen, wir wollen unsere Styles-Daten laden, so schreiben wir in die calendar.blade.php noch rein, dass er zum Beispiel noch styles.css mit laden soll:
<link rel="stylesheet" href="{{asset('css/styles.css')}}">
Im Ordner public/css/ muss die Datei natürlich existieren
Du siehst {{asset('css/styles.css')}} und das bedeutet, dass Laravel diesen Helper dazu benutzt, hier auch wirklich den richtigen Pfad zu hinterlegen. Die Styles werden nun automatisch geladen und die Seite wird dann entsprechend hübscher. Laravel kann auch Sass und Co, für diese Einführung reicht das aber erst einmal.
Datenbankmodelle
Aktuell zeigt unser View 2 Termine an. Reichlich unspektakulär und leider auch nicht wirklich flexibel. Wir wollen ja schließlich, dass unsere Termine dynamisch gespeichert werden können. Wir wollen Termine verändern können. Wozu haben wir denn den tollen Controller geschrieben?!
Überlegungen
Unser Terminkalender soll ein Datum speichern können und dazu einen Informationstext, was an diesem Datum eigentlich ist. Wir könnten jetzt in phpmyadmin einfach eine Tabelle erstellen und diese aus 2 Feldern zusammen bauen:
- Datum des Termins
- Beschreibung des Termins
Machen wir aber nicht.
Ein Modell und eine Migration erstellen
php artisan make:model Termine -m
Laravel erstellt mit diesem Einzeiler 2 Dateien. Im Ordner /app findest du nun eine Datei namens Termine.php und im Ordner /database/migrations findest Du eine Datei, die in etwa so heißt: 2019_xx_xx_094728_create_termines_table.php
In dem Ordner sind noch andere Skripte, die ignorieren wir gerade aber mal. Folgendes schreiben wir nun in die up()-Methode
public function up()
{
Schema::create('termines', function (Blueprint $table) {
$table->bigIncrements('id');
$table->text('terminbeschreibung'); // Was machen wir am Termin?
$table->dateTime('termindatum'); // Wann findet der Termin statt?
$table->timestamps();
});
}
Diese Migration legt fest, dass wir eine Spalte namens “terminbeschreibung” haben wollen. Ausserdem wollen wir ein Termindatum. Die Tabelle bekommt noch eine ID-Spalte und es werden Zeitstempel-Spalten hinterlegt.
Führen wir nun dies hier aus
php artisan migrate:fresh
Im Idealfall läuft dein Skript durch und in deiner Datenbank befindet sich nun die Tabelle termines und weitere Tabellen, die uns aber im Moment auch noch nicht interessieren.
Allerdings kann es vorkommen, dass es nicht klappt. Einen Fix für dieses Problem gibt es hier: https://stackoverflow.com/questions/53115172/how-to-install-laravel-with-older-versions-of-mariadb-and-mysql-exception-when
Benutze immer die Laravel-Migrationen, um Tabellen zu erstellen und/oder zu verändern. Falls Du in einem Team von Leuten arbeitest, kann jeder mit identischen Tabellenstrukturen arbeiten. Außerdem kann jeder mit seiner Lieblingsdatenbank arbeiten. Da Laravel eine Vielzahl von Datenbanken unterstützt, kann man hier völlig unabhängig von der Datenbank mit denselben Codes arbeiten.
Daten im View darstellen
Controller zieht Daten
(Laravel bietet Methoden, um “Testdaten” anzulegen. Um diesen Crashkurs so einfach wie möglich zu halten, machen wir das jetzt aber nicht.)
In termines fügen wir jetzt mal 2 Zeilen über phpmyadmin ein.
Nun überarbeiten wir zuerst einmal unseren Controller. Laravel soll die Variable termine mit allen Daten aus der Tabelle aus SQL füllen.
class CalendarController extends Controller
{
/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/
public function index()
{
$termine = \App\Termine::all();
return view('calendar', array('ausgabe'=>$termine));
}
Wenn wir jetzt http://localhost:8000/termine aufrufen, kommt unsere Seite von vorhin wieder. Leider sind die Termine noch immer nicht aus unserer Datenbank, sondern sehen genau so aus, wie vorher.
View anpassen
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Calendar</title>
</head>
<body>
<h1>Kalenderübersicht</h1>
<div>
<h2>Anstehende Termine für Heute</h2>
<ul>
@foreach ($ausgabe as $termin)
<li>{{$termin->termindatum}}
- {{$termin->terminbeschreibung}}
</li>
@endforeach
</ul>
</div>
</body>
</html>
Neu ist jetzt, dass wir eine Template-Variable nutzen. Diese Variable heißt ausgabe und wird in einer foreach-Schleife in einzelne Zeilen ausgegeben. Im CalendarController haben wir festgelegt, dass an den view calendar.blade.php die Variable termine an die Template-Variable ausgabe übergeben werden sollte.
Und jetzt kommen unsere Termine tatsächlich aus einer Datenbank.
Was kommt im nächsten Teil?
Wir schreiben Templates mit Formularen, um neue Datensätze zu erstellen. Dabei werden wir feststellen, dass es ganz praktisch wäre, wenn man Teilbereiche des Templates wiederverwenden könnte. Außerdem stellen wir fest, dass es ziemlich dämlich ist, wenn jeder einfach so Termine eintragen kann.
