Mit dem dritten Meilenstein öffnet sich der Kalender nach außen. Besucherinnen und Besucher der Website sehen die freien Zeiten eines Tages und fragen einen Termin an, ohne Skript und ohne Konto. Einzelteile davon haben Sie gebaut: die Regel für freie Zeiten in Lektion 2.5.6, die Buchung in Schritten, eine erste Ratenbegrenzung und ein Honeypot-Feld in Lektion 2.6.6. Jetzt kommt alles zusammen, und es kommt etwas dazu, das erst durch Meilenstein 2 möglich ist: Eine Buchung belegt dieselben Viertelstunden wie ein Termin des Büros. Dann kann die Datenbank beide gegeneinander schützen.

Pull Request Branch Bringt Wo in dieser Lektion
1 feature/m3-booking-options Öffnungszeiten je Wochentag, Pausen, Tage im Voraus, beim Start geprüft „Pull Request 1“
2 feature/m3-free-slots die vollständige Regel für freie Zeiten Übung 1
3 feature/m3-booking-is-appointment eine Buchung ist ein Termin; „inzwischen vergeben“ „Pull Request 3“
4 feature/m3-limits Ratenbegrenzung je Besucheradresse, Honeypot-Feld „Pull Request 4“ und Übung 2

Wo die Kladde steht

Nach Meilenstein 2 gilt in den Lösungen:

  • BookingOptions aus Lektion 2.3.4 kennt seit Lektion 2.5.6 die Öffnungszeiten je Wochentag (Hours), eine Mittagspause (BreakStart, BreakEnd), die Dauer eines Termins (SlotMinutes), den Vorlauf (LeadHours) und die Zeitzone (TimeZoneId). Die Options liegen in Kladde.Web und werden beim Start geprüft; ToRules() macht daraus die BookingRules des Kerns.
  • FreeSlots in Kladde.Core berechnet die freien Zeiten eines Tages (Lektion 2.5.6), mit den Grenzfällen vergangener Tag, Tag der Zeitumstellung, Mittagspause und voller Tag.
  • Eine Buchung ist eine eigene Tabelle mit Beginn, Name und E-Mail-Adresse. Ein eindeutiger Index auf dem Beginn verhindert seit Lektion 2.4.10, dass dieselbe Zeit zweimal gebucht wird.
  • Die Buchungsseite /termin führt in Schritten durch Tag, Zeit und Angaben; seit Lektion 2.6.6 ist sie begrenzt und hat ein Honeypot-Feld. Nach dem Buchen zeigt /termin/gebucht den Termin (Lektion 2.5.6).
  • Seit Lektion 2.8.5 gilt eine Buchung erst, wenn die Person den Link in ihrer Mail bestätigt hat. Die Bestätigung geht über den Postausgang aus Lektion 2.8.4 hinaus.
  • Termine des Büros belegen seit Meilenstein 2 ihre Viertelstunden in AppointmentSlots.

Das Problem in diesem Stand: Buchungen und Termine des Büros wissen nur über die Regel im Modell voneinander. Bucht ein Besucher 10 Uhr, während jemand im Büro gerade 9:30 bis 10:30 Uhr einträgt, bestehen beide ihre Prüfung, und die Datenbank hält beide für gültig.

Die Beispiele dieser Lektion legen die Optionen selbst in den Kern und nennen die Zeitzone TimeZone. Mit der Lösung von Lektion 2.5.6 bleiben BookingOptions in Kladde.Web und BookingRules im Kern. Pull Request 1 bringt dann nur, was neu ist: eine Liste von Pausen statt der einen Mittagspause, DaysAhead und die Prüfung gegen die Viertelstunden aus Meilenstein 2; ToRules() reicht alles an die Regel weiter. Heißen Ihre Dateien, Klassen oder Ordner anders, behalten Sie Ihre Namen und übertragen Sie die Schritte.