Ankündigung

Einklappen
Keine Ankündigung bisher.

Routing mit json Dateien

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Routing mit json Dateien

    Hi,

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

    Code:
    {
     "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


  • #2
    Ließ das ganze als Array ein, nicht als Object. Damit lässt sich dann leichter arbeiten, dann kannst du alle routes per foreach durchgehen.
    Zitat von nikosch
    Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

    Kommentar


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

      Kommentar


      • #4
        Das Format ist doch wohl Hupe.
        [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

        Kommentar


        • #5
          Zitat von tr0y Beitrag anzeigen
          Das Format ist doch wohl Hupe.
          Wieso denkst du, dass das Format Hupe ist?

          Kommentar


          • #6
            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.
            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

            Kommentar


            • #7
              Wenn Du meinst. Danke für die Antwort.

              Kommentar


              • #8
                Zitat von ParseError Beitrag anzeigen
                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.
                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                Kommentar


                • #9
                  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
                  Standards - Best Practices - AwesomePHP - Guideline für WebApps

                  Kommentar


                  • #10
                    Zitat von rkr Beitrag anzeigen
                    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.
                    Zitat von nikosch
                    Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

                    Kommentar


                    • #11
                      Zitat von tkausl Beitrag anzeigen
                      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?
                      Standards - Best Practices - AwesomePHP - Guideline für WebApps

                      Kommentar


                      • #12
                        Zitat von rkr Beitrag anzeigen
                        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

                        Zitat von rkr Beitrag anzeigen
                        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...
                        Zitat von nikosch
                        Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

                        Kommentar


                        • #13
                          Zitat von tkausl Beitrag anzeigen
                          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?
                          Standards - Best Practices - AwesomePHP - Guideline für WebApps

                          Kommentar


                          • #14
                            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.

                            Code:
                            return [
                             'name' => '...',
                             'description' => '...',
                             /* ... */
                            ];
                            sieht einfach technischer aus als
                            Code:
                            {
                             "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.

                            Kommentar


                            • #15
                              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.

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


                              PHP-Code:
                              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.
                              --

                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                              --

                              Kommentar

                              Lädt...
                              X