Tut es auch, indem es ein Interface dafür zur Verfügung stellt - Daher sehe ich da auch keinen Bruch.
Ich hab ja auch ein kleines, prozedurales Framwork:
da läuft alles über eine index.php, je nach Parameter werden andere Dateien
(Sprachdateien, php-Programmlogik-Dateien und Ausgabedateien includet
und am Ende alles ausgegeben (EVA-Prinzip).
Läuft sehr gut, sehr schnell, ist gut dokumentiert und andere Programmierer
die schon mal etwas anpassen/ändern mußten haben die Übersichtlichkeit etc. gelobt.
Wenn ich jetzt ein neues Projekt starte kopier ich eine der vielen Anwendungen die
der aktuellen am nächsten kommt, ändere die DB, trag config-Daten ein und mach die
Anpassungen am Verarbeitungs- und Ausgabecode die eben notwendig sind.
So scheints Du auch zu arbeiten, eben in OOP und mit dem Unterschied
daß Du jedes mal noch Dein Framework umbauen mußt wenn neue Anforderungen
wie Mehrsprachigkeit hinzukommen.
Wenn ich aber jedes Mal oder fast jedes Mal mein Framework umbauen,
in den Core eingreifen muß. dann ist das kein Framework mehr, dann ist das Copy/Paste
von existerienden Projekten.
Ist ja auch kein Problem, kannst ja so machen wenn es für Dich paßt.
Nur versteh ich Deine Kritik am APF nicht und Dein Beharren darauf daß man alles auch anders
machen kann als es im APf umgesetzt ist.
Natürlich kann man beispielsweise auch eine Hintertür namens "helper" einbauen und dann unter dem
Vorwand der Produktivität und weil man schnell was Hinzubasteln kann die Integration
von Helpern in der Form wie es das beispielsweise das ZF tut rechtfertigen.
Weiter- oder zielführend ist das nicht und ein schlüssiges Gesamtkonzept anwendbar für
alle denkbaren Fälle läßt sich daraus nicht ableiten.
Kommentar