Routing mit json Dateien

[Lokart]

Hi,

ausgehend von einem modularen System, in dem jedes Modul über eine entsprechende json-Datei definiert, z.B.:

{
 "name": "Great module",
 "version": "1.0.0",
 "routes": [
   {
      "/": "ControllerName@ControllerAction"
   }
 ]
}

Die Frage: wie lese ich die json-Datei am Besten aus um die Routen zu definieren? Via json_decode bekomme ich ein Objekt, dass als Member "/" hat - ich werde wohl kaum "$obj->/" schreiben können.

Nachtrag:
$obj->{'/'} funktioniert tatsächlich, behebt mein Problem aber nicht. Ich bekomme eine Liste von Objekten und muss deren Path auslesen (in genanntem Beispiel "/"). Nachdem der Loader ja nicht weiß, welcher Pfad das ist, tu ich mir etwas schwer drauf zuzugreifen. Oder ich denke gerade einfach zu kompliziert.

Schöne Grüße

[nikosch]

Für eindimensionale (max. 2-dim.) Daten böte sich auch ein schlichtes ini-Format an. Die korrekte Klammerung un Interpunktion von JSON ist nämlich auch nicht gerade laienfreundlich.

{
 "name": "Great module",
 "version": "1.0.0",
 "routes": [
   {
      "/": "ControllerName@ControllerAction"
   }
 ]
} 

name  = "Great module"
version = "1.0.0"

[routes]

"/" = "ControllerName@ControllerAction" 

Die nächste Frage ist allerdings, ob ein Laie überhaupt irgendwelche Routing-Geschichten ändern sollte.

[Lokart]

Ich werde das json als Array verarbeiten. Danke.

Und da hier die Diskussion aufkam bzgl. "warum json, wenns PHP auch kann":
Wie schon gesagt wurde, ist json "sympathischer" zu bearbeiten.

return [
 'name' => '...',
 'description' => '...',
 /* ... */
];

sieht einfach technischer aus als

{
 "name": "...",
 "description": "..."
}

Jemand der von PHP keine Ahnung hat, weiß vielleicht nicht, was das "return" da macht. Oder warum er "=>" schreiben muss. Vielleicht vergisst er solche Dinge dann mal und es kommt zu Fehlern.

Die Frage nach "Yaml oder json" lässt sich einfach damit beantworten, dass ich json bevorzuge. Nicht, weil yaml nicht gut sei oder ähnliches, sondern weil ich sich json in meinen bisherigen Projekten bewährt hat.

[rkr]

Weil es einfach besser zu lesen ist. Grade für den Endanwender der keine Ahnung hat. Was meinst du wie oft ich es gesehn habe, dass ein Kunde die "" mit weggemacht hat um etwas zu ändern...

Yaml würde dieses Argument locker behaupten können. Aber json?

[tkausl]

Zumal man von allen infrage kommenden Config-Originaldateien ständig ein mtime check machen wird, damit man eine Änderung feststellen kann.

Ich nutze Symfony, dort wird kein Check (im Production-Env) gemacht. Wenn man was ändert -> clear & warmup cache

Nur wozu noch ein Fremdformat, wenn php selbst sich für sowas recht gut eignet?

Weil es einfach besser zu lesen ist. Grade für den Endanwender der keine Ahnung hat. Was meinst du wie oft ich es gesehn habe, dass ein Kunde die "" mit weggemacht hat um etwas zu ändern...

[rkr]

Das Parsing muss ja nur einmalig (nach dem ändern) passieren, danach wird wie du schon sagst gecached. Außerdem erfasst der opcode-cache dann auch diese Cache-PHP-Dateien also ist das Argument hinfällig.

Wenn man es denn so macht. Der TS hat ja nichts in der Hinsicht angedeutet. Zumal man von allen infrage kommenden Config-Originaldateien ständig ein mtime check machen wird, damit man eine Änderung feststellen kann. Man kann alles bis ins letzte Detail perfektionieren. Nur wozu noch ein Fremdformat, wenn php selbst sich für sowas recht gut eignet?

[tkausl]

Ich bin weniger ein Freund davon, alles in fremden Formaten zu verklausulieren, wenn man das dann erst immer noch parsen muss. Wird das dann gecacht liegt das, was PHP tatsächlich läd liegt, dann irgendwo anders. In PHP gehaltene Konfigurationsdateien werden von opcode-cachern erfasst und danach schneller verarbeitet.

Das Parsing muss ja nur einmalig (nach dem ändern) passieren, danach wird wie du schon sagst gecached. Außerdem erfasst der opcode-cache dann auch diese Cache-PHP-Dateien also ist das Argument hinfällig.

[rkr]

Ich bin weniger ein Freund davon, alles in fremden Formaten zu verklausulieren, wenn man das dann erst immer noch parsen muss. Wird das dann gecacht liegt das, was PHP tatsächlich läd liegt, dann irgendwo anders. In PHP gehaltene Konfigurationsdateien werden von opcode-cachern erfasst und danach schneller verarbeitet. In (Php54 vorausgesetzt) sehen Arrays mit ShortArrayDings auch nicht mehr so viel anders aus als JSON (Anzahl benötigter Bytes ist nur geringfügig höher). Naja, jeder wie er muss

[tr0y]

Wenn Du meinst. Danke für die Antwort.

Wissen, nicht meinen. Nicht umsonst bringen aktuelle (prominente) Frameworks mehr wie ein Konfigurationsformat von Hause aus mit.

Wenn Du meinst. Danke für die Antwort.

[tr0y]

Weil das Format egal ist. Einzig das was favorisiert ( hier offenbar JSON ) ist entscheidend. Denn zwischen einem deserialisierten JSON-to-Array Cast und einem PHP Array ist resultat-technisch kein Unterschied, nur das ( beautified ) JSON schöner aussieht.

YAML, XML oder selbst INI-Files kann er zum Konfigurieren nutzen.

Das Format ist doch wohl Hupe.

Wieso denkst du, dass das Format Hupe ist?

[tr0y]

Das Format ist doch wohl Hupe.

Welches Problem versuchst Du zu lösen indem Du JSON dafür einsetzt? Was spricht gegen z.b. routes.php?

[tkausl]

Ließ das ganze als Array ein, nicht als Object. Damit lässt sich dann leichter arbeiten, dann kannst du alle routes per foreach durchgehen.