Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Scope Problem

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Scope Problem

    Hallo zusammen,

    ich möchte folgenden Prozess umsetzen:

    1. SOAP Client A ==[SOAP Request]=> SOAP Server Method
    2. SOAP Server Method ==[HTTP Redirect]=> Fremder Server
    3. Fremder Server ==[HTTP Redirect]=> SOAP Server Method
    4. SOAP Server Method ==[SOAP Response]=> SOAP Client A

    Ein Soap-Client stellt eine Soap-Anfrage an einen Soap-Server. Dieser sammelt dann einige Daten und führt einen Redirect via HTTP an eine fremde Schnittstelle aus (...anderer Server). Die fremde Schnittstelle meldet sich dann mit einen HTTP Redirect und ein paar zusätzlichen Header- und Get-Parametern am Soap-Server zurück. Die mitgelieferten Parameter werden ausgewertet. Abhängig vom Resultat möchte ich dann ein bestimmtes Ergebniss zurück an den Aufrufenden Soap-Client kommunizieren.

    Mein Problem hierbei ist der Scope.

    Variante Nr.1:
    Beim Http-Redirect aus der Soap-Server-Klasse zur fremdem Schnittstelle und anschliessendem zurückkehren wird eine neue Instanz der Klasse erzeugt. Ich befinde mich nicht mehr im aktuellen Scope.

    Variante Nr. 2:
    Ich hatte gedacht es hilft mir wenn ich die Klasse als Singleton aufbaue und damit neue Instanziierungen verhindere. Dann habe ich aber das Problem, dass ich nach der Verarbeitung nicht einfach mit return=$result an die Server-Klasse zurückgeben und damit dem Client nichts zurückschicken kann.

    Das Konstrukt soll in PHP5 ohne Ajax oder andere Frameworks umgesetzt werden.

    Vielleicht hat jemand von euch eine Idee wie ich das aufziehen kann. Mir fällt jedenfalls gerade nichts mehr ein.

    LG,
    Tviskjola


  • #2
    Das kannst Du bei HTTP vergessen, würde ich sagen. Singleton hat damit auch nicht die Bohne zu tun. Wozu der ganze Aufwand?
    --

    „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


    • #3
      Vorgegebene Rahmenbedingungen

      Zitat von nikosch Beitrag anzeigen
      Das kannst Du bei HTTP vergessen, würde ich sagen. Singleton hat damit auch nicht die Bohne zu tun. Wozu der ganze Aufwand?
      Hi,

      ich würde mich auch eine andere Basis wünschen, aber es handelt sich dabei um einen PaymentProzessor der mit PayPal und ClickandBuykommuniziert. Und deren Schnittstellen stehen leider fest.

      LG,
      Tviskjola

      Kommentar


      • #4
        Und wieso entstehen dabei Redirects?!
        --

        „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


        • #5
          Redirects

          Zitat von nikosch Beitrag anzeigen
          Und wieso entstehen dabei Redirects?!
          Hi,

          bei der Kommunikation z.B. mit der ClickandBuy-API muss ich zuerst einen Payment-Link zusammenbauen, diesen dann (den User-Click simulierend) via HTTP-Redirect aufrufen. Der Payment-Link ruft dann innerhalb der ClickandBuy-Engine mein Script erneut auf. Das Script validiert dann die empfangenen Header-Parameter und führt einen weiteren Redirect via HTTP mit einem Success Parameter aus, ebenfalls wieder auf mein Script.

          Jede Menge HTTP Redirects...leider. Und jedesmal wird mein Script nach einem Redirect erneut aufgerufen und ich instanziiere neu.

          Schräges Konstrukt, ich weiss

          @Edit: Singleton hat in sofern etwas damit zu tun, als dass ich nach jedem HTTP-Redirect auf meine eigene Klasse diese neu instanziiere, was ich mit dem Singleton Pattern verhindern wollte damit mir nicht immer die ganzen Daten flöten gehen. Mag sein, dass der Ansatz unpraktikabel ist, das geb ich gern zu^

          Kommentar


          • #6
            Da du einen neuen Scriptaufruf hast, wirst du wohl nicht drumherum kommen neue Instanzen der Klassen zu haben.
            Das einzige was du machen könntest wäre die entsprechenden Instanzen zu cachen... Serialisiert oder anders wiederherstellbar zwischenzuspeichern. Dafür gibt es ja entsprechende magische Methoden.

            Kommentar


            • #7
              Magische Methoden

              Zitat von Papst Beitrag anzeigen
              Da du einen neuen Scriptaufruf hast, wirst du wohl nicht drumherum kommen neue Instanzen der Klassen zu haben.
              Das einzige was du machen könntest wäre die entsprechenden Instanzen zu cachen... Serialisiert oder anders wiederherstellbar zwischenzuspeichern. Dafür gibt es ja entsprechende magische Methoden.
              Hi,

              ok, das wäre zumindest ein Ansatz. Hab ich noch nie ausprobiert und schau ich mir nachher mal an. Damit ich das richtig verstanden habe:

              Du meinst serialize() und unserialize() in Verbindung mit __sleep() und __wakeup() richtig?

              LG,
              Tviskjola

              Kommentar


              • #8
                ja.
                Kann dir aber leider auch nicht viel zu sagen, da ich es selber noch nie ausprobiert habe.

                Kommentar


                • #9
                  Ich suche noch ein bissel die Relevanz, warum die Instanz fortgeführt werden muss.
                  --

                  „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


                  • #10
                    Scope

                    Zitat von nikosch Beitrag anzeigen
                    Ich suche noch ein bissel die Relevanz, warum die Instanz fortgeführt werden muss.
                    Hi,

                    es wäre nicht unbedingt notwendig die Instanz fortzuführen. Die entstehenden Daten könnte ich ja zumindest in einer Session bis zum nächsten Aufruf wegspeichern, oder wie ja bereits oben vorgeschlagen mit serialize und sleep sichern und in der nächsten Instanz versuchen wieder herzustellen.

                    Das eigentliche Problem ist, dass ich - wenn durch die HTTP-Redirects auf die Klasse selbst jedesmal neu instanziiert wird, ich scheinbar nicht sauber mit einem Return zu der Klasse zurückkehren kann die die allererste Instanz aufgerufen hat.

                    Ich bin jetzt aber auch an einem Punkt angekommen wo mir das Konstrukt zu abgedreht und unpraktikabel wird, weshalb ich jetzt eine Ebene höher versuche die Architektur umzustellen um sowas dann nicht mehr machen zu müssen.

                    Ich bedanke mich bei euch für eure Zeit und eure Geisteskraft.

                    Viele Grüße,
                    Tviskjola

                    Kommentar


                    • #11
                      Zitat von Tviskjola Beitrag anzeigen
                      Das eigentliche Problem ist, dass ich - wenn durch die HTTP-Redirects auf die Klasse selbst jedesmal neu instanziiert wird, ich scheinbar nicht sauber mit einem Return zu der Klasse zurückkehren kann die die allererste Instanz aufgerufen hat.
                      Natürlich kannst du das nicht - weil es diese Instanz gar nicht mehr gibt.

                      Objektinstanzen „leben“ in PHP nur so lange, wie das Script läuft.
                      Und im Web-Umfeld ist es die Regel, dass ein Script sich um genau einen HTTP-Request kümmert, und „stirbt“, wenn es mit dessen Bearbeitung fertig ist.

                      Kommentar


                      • #12
                        Genau. Du musst letzendlich Script-basiert (bzw. in Requests) denken. Eine recht brauchbare Analogie ist die Post.
                        --

                        „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