Codeigniter API Nginx

[pl]

Tach!

Wobei ich es sowieso schon bedenklich finde, Namen von Klassen und Methoden über den URI zu schleifen. Besser ists, OOP eben konsequent zu nutzen, sowas gehört in die Konfiguration und zwar als Eigenschaft und nach draußen nicht sichtbar. Ansonsten zöge ja eine Änderung des Klassenname eine Änderung des URL mit sich, brr.

Man ändert einen Klassennamen nicht ohne Grund, wenn sich daraus auch Teile der URL ergeben. Wenn man per Konvention routet (sprich wenn aus der URL per Regel der Controller- und Action-Name gebildet werden), dann benennt man seine Klassen passend, und dass Änderungen sich auf die URL auswirken ist dann auch gewollt. Sowas generell als schlecht abzutun, ohne einen konkreten Anwendungsfall zu betrachten, ergibt keinen Sinn.

Es ist grottenschlecht, weil es zu sinnbefreiten Abhängigkeiten führt. Und es geht an OOP komplett vorbei. Wozu gibt es denn OOP wenn man sie nicht konsequent nutzt!?

Zudem haben Router oft die Eigenschaft, neben dem Routen nach Konvention auch nach konfigurierten Einträgen routen zu können. Falls also der Klassename unabhängig von der URL geändert werden soll, setzt man da eine Konfiguration obendrauf und gut ist.

Z.B. Das kann man aber auch gleich so machen: Klassenbindung und Eigenschaften.

Üblicherweise gestaltet man ein Framework so, dass die Controller von einer definierten Klasse abstammen

Wozu? Und was heißt hier üblich!? In meinem FW arbeite ich mit sog. Traits, die sind klassenunabhängig. Ein Trait, der Methoden des Interface definiert, wird erst infolge der Konfiguration einer bestimmten Klasse zugewiesen. Beispiel eine meiner Seiten:

<!-- class: HTMLfile -->
<!-- interface: date --> 

Die Klasse HTMLFile führt zum Boddy der auszugebenden Seite, hierzu wird die konfigurierte Eigenschaft file=home.html benutzt die den Pfad zum Template weist.

Die Eigenschaft interface=date bindet den Trait. Da stecken die Methoden des FW Interface drin und auch der Controller ist eine solche Methode. Sind Parameter im Request, wird control() aufgerufen. Das ist bei allen URLs gleich. Wobei control() auch nur ausgeführt wird, wenn diese Methode definiert ist. Ist sie es nicht, kann der gebundene URL keine Benutzereingaben verabeiten.

Ansonsten sind alle Methoden des FW Interface in der Lage, Platzhalter mit Daten zu befüllen. Interface date setzt z.B. das aktuelle Datum in einen Platzhalter.

Du siehst also, hier gäbe es unendlich wiele Möglichkeiten Klassen sowie Traits an URLs zu binden, sozusagen eine n:n Beziehung. Konfigurierbar und unabhängig vom URL! Sowas macht Sinn!

MfG