2. Fortsetzung: Termine

[Rolf B]

Hallo Regina,

so, jetzt bin ich mal zum tieferen Überfliegen deines Codes gekommen.

Hast Du das für dieses Posting zusammengeschneidert? Oder lag das fertig in deiner Code-Schublade? Ich vermute ersteres, z.B. ist das Errorhandling unvollständig (z.B. ohne setlocale() sind keine Tages-/Monatsnamen da und man greift auf null mit Array-Operatoren zu).

Ich bin auch mit den setYear.../setMonth... Methoden unzufrieden; das ist Datumsarithmetik und der Rest Deiner Klasse befasst sich dem Rendern des HTML für einen Kalender. Da werden Concerns vermischt.

Trotz der kleinen Kritik: für ein "schnelles Beispiel" ist das eine ganze Menge, was Du da gebaut hast. Das Thema "Datenversorgung" hätte ich beinah kritisiert - aber dann gesehen dass Du das als Übung für Bernd zurückgestellt hast.

Für Bernd ist es ein Beispiel, wie man Code in Klassen kapseln kann, und es zeigt einige I18N Aspekte. Es sind auch wichtige Vorschläge für's HTML drin. Für ein OOP Muster ist allerdings die getCalendar Methode viel zu unhandlich, da muss man nochmal dringend mit der Axt ran und sie in kleinere Elemente zerlegen. Das Wochen-Handling gehört z.B. in eine private beginRow Methode, die dann vor der Schleife sowie in der Schleife aufgerufen wird. Die Ermittlung von $class sollte auch isoliert sein, etc.

Für die Datenversorgung könnte man eine abstrakte Methode renderDay($datum) vorsehen. Ein Anwender kann dann eine Subklasse erzeugen, renderDay überschreiben und darüber das Markup für einen Tagesinhalt zurückliefern. Die nötige SQL Abfrage KÖNNTE dann in renderDay stattfinden, oder man greift auf einen bereits geladenen Datenbestand zu.

Ich hoffe, ich komme morgen dazu, mein prozedurales Refactoring vorzustellen.

Rolf