Paul!!: php function und javascript

Hi,

ich möchte an einer Stelle eines Funktionsaufrufes einen Wert wissen, der sich erst später ergibt.

Konkret:

zeige_zeilen("Es werden XY Zeilen aufgeführt");
include("meine_include_datei.php");

Ich würde gerne die Funktion selber unberührt lassen, weil ich sie in anderen Kontexten noch benutze.

Ist es irgendwie möglich, den XY-Wert im Parameterstring, der sich erst aus der "meine_include_datei.php" ergibt, per JS im Nachhinein einzutragen? Welche Möglichkeiten bleiben mir sonst noch (falls das nicht möglich ist)

Paul

  1. Tach!

    ich möchte an einer Stelle eines Funktionsaufrufes einen Wert wissen, der sich erst später ergibt.

    Wie soll das funktionieren? Die Funktion wird an der Stelle aufgerufen und ist dann Geschichte. Es gibt keine Möglichkeit, sie bis zum Eintreffen irgendeiner Bedingung zu verzögern und mit dem Rest des Scripts fortzufahren.

    Ist es irgendwie möglich, den XY-Wert im Parameterstring, der sich erst aus der "meine_include_datei.php" ergibt, per JS im Nachhinein einzutragen?

    Na das gleich gar nicht. Wenn Javascript auf dem Client läuft, ist PHP auf dem Server schon längst fertig. Normalerweise muss alles, was der Client dem Server mitteilen soll, ein eigener Request sein. Abgesehen davon gibt es Techniken wie Websockets, die eine ständige Verbindung simulieren.

    Welche Möglichkeiten bleiben mir sonst noch (falls das nicht möglich ist)

    Für welches eigentliche Problem?

    dedlfix.

  2. Hallo,

    ich möchte an einer Stelle eines Funktionsaufrufes einen Wert wissen, der sich erst später ergibt.

    \i da brauchst du eine Zeitreise...

    zeige_zeilen("Es werden XY Zeilen aufgeführt");
    

    das ist ein eher ungewöhnlicher Funktionsaufruf, sollte die Funktion nicht eher eine Zahl übergeben bekommen und dann den Text zurückgeben?

    include("meine_include_datei.php");
    

    Das hier wird serverseitig eingefügt, während das Javascript erst dann loslegt, wenn der Browser tätig wird.

    Ich würde gerne die Funktion selber unberührt lassen, weil ich sie in anderen Kontexten noch benutze.

    ?

    Ist es irgendwie möglich, den XY-Wert im Parameterstring, der sich erst aus der "meine_include_datei.php" ergibt, per JS im Nachhinein einzutragen?

    Per Javascript kannst du die ausgegebene Webseite noch verändern. Du kannst aber nicht rückwärts auf die PHP-Ausgabe Einfluss nehmen.

    Du müsstest mal dein/e eigentliche/s Problem/Aufgabe schildern.

    Gruß
    Kalk

  3. Hallo und guten Morgen,

    ich möchte an einer Stelle eines Funktionsaufrufes einen Wert wissen, der sich erst später ergibt.

    Konkret:

    zeige_zeilen("Es werden XY Zeilen aufgeführt");
    include("meine_include_datei.php");
    

    Ich würde gerne die Funktion selber unberührt lassen, weil ich sie in anderen Kontexten noch benutze.

    Ist es irgendwie möglich, den XY-Wert im Parameterstring, der sich erst aus der "meine_include_datei.php" ergibt, per JS im Nachhinein einzutragen? Welche Möglichkeiten bleiben mir sonst noch (falls das nicht möglich ist)

    Der Designfehler oder auch das notwenige (?) Forward befinden sich auf dem Server. Warum willst Du es dann noch in den Client verschleppen und damit die Unsicherheit einer richtigen und vollständigen Bearbeitung des Requests noch erhöhen?

    Es gibt nur zwei Möglichkeiten:

    1. Das Design ändern und die Funktionsausführung erst nach der Festlegung der notwendigen Parameter anstoßen.

    2. Die Funktion nur Platzhalter bereitstellen lassen, die erst (kurz) vor der Ausgabe mit den bis dahin (hoffentlich) bekannten Werten gefüllt werden.

    In zweiten Fall muss die Ausgabe verzögert werden. PHP bietet dazu den Output-Buffer an.
    http://php.net/manual/en/ref.outcontrol.php
    Mit ob_start() kannst du den Buffer starten, dann später im Buffer die Platzhalter tauschen gegen die Werte und ganz zum Schluss die Ausgabe veranlassen.

    Derartige Probleme treten meistens dann auf, wenn man HTML und PHP bunt mischt, z. B., wenn man in ein Mastertemplate (HTML) PHP-Ausgaben einbauet und einm dann erst später einfällt, dass der Wert des <title>-Tag noch mit einem Wert gefüllt werden muss, der sich aus den Includes (z.B. Auswertung der POST-Parameter) ergibt.

    Es ist daher besser, Requestauswertung, Werteberechnung und -Beschaffung, Festlegung des Markups und erst zum Ende die Ausgabe zu trennen. Siehe auch EVA-Prinzip.

    Grüße
    TS

  4. Hi alle,

    vielleicht hab ichs falsch beschrieben. Die Funktion ist eigentlich eine reine Designfunktion. Sie baut mir einige DIVs so auf, daß sie für mich quasi ein Template baut, das ich je nach Parameter mit Inhalt bestücke. In vorliegendem Fall setzt sie eine Überschrift ein, daher wird ein String übergeben. Wer jetz auf Designfehler pocht, sollte mal den Ball flach halten, ich arbeite damit in verschiedenster Form seit fast 6 Jahren und erhalten ein wunderbares einheitliches Design und habe beim Programmieren nahezu Null Arbeit damit.

    Die Lösung zu meinem Problem fiel mir beim morgenlichen Gassi gehen mit dem Hund selber ein.

    Ich kann doch als Stringparamter auch einen DIV-Block übergeben, den ich schlußendlich per JS mit einem beliebigen Text füllen kann.

    Ich werde das mal angehen...

    Paul

    Konkret:

    zeige_zeilen("Es werden XY Zeilen aufgeführt");
    include("meine_include_datei.php");
    
    1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

      Hi alle,

      vielleicht hab ichs falsch beschrieben. Die Funktion ist eigentlich eine reine Designfunktion. Sie baut mir einige DIVs so auf, daß sie für mich quasi ein Template baut, das ich je nach Parameter mit Inhalt bestücke. In vorliegendem Fall setzt sie eine Überschrift ein, daher wird ein String übergeben.

      grins ist ja genau das Szenario, dass TS beschrieben hat.

      Wer jetz auf Designfehler pocht, sollte mal den Ball flach halten, ich arbeite damit in verschiedenster Form seit fast 6 Jahren und erhalten ein wunderbares einheitliches Design und habe beim Programmieren nahezu Null Arbeit damit.

      Das ist eindeutig ein Designfehler - Fehler im Programmdesign, hat nichts mit bunten Bildern zu tun ;-)

      Und die Medizin dagegen könnte, wie schon erwähnt, Output-Buffer heißen. Die ändeet aber nichts an der Krankheit, sondern lindert nur die Schmerzen...

      Spirituelle Grüße
      Euer Robert
      robert.r@online.de

      --
      Möge der wahre Forumsgeist ewig leben!
      1. Hi,

        Das ist eindeutig ein Designfehler - Fehler im Programmdesign, hat nichts mit bunten Bildern zu tun ;-)

        Sehe ich anders.

        Ich benutze JS hier genau dafür, wozu es gedacht ist. Ich setze clientseitig in ein DIV einen Wert ein, den ich im Verlauf des Scripts gerneriere/erhalte.

        Das DIV widerum generiere ich dynamisch, und zwar über eine Funktion.

        Wo ist das Problem für Dich?

        Paul

        1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

          Wo ist das Problem für Dich?

          mein Browser benutzt kein Javascript.

          Spirituelle Grüße
          Euer Robert
          robert.r@online.de

          --
          Möge der wahre Forumsgeist ewig leben!
          1. mein Browser benutzt kein Javascript.

            Das soll ein Problem sein? Dein Browser wird auch meine Software nie! benutzen. Problem ist also hiermit gelöst :)

            Paul

            1. Hallo und guten Abend,

              mein Browser benutzt kein Javascript.

              Das soll ein Problem sein? Dein Browser wird auch meine Software nie! benutzen. Problem ist also hiermit gelöst :)

              Ich hoffe, dass das jetzt nicht persönlich gemeint ist, sondern Du damit nur ausdrücken willst, dass Du ausschließlich für eine genau bekannte Client-Schaar verwickelst (sic!). Da kann man dann Fehler auch durch Gegenfehler wieder ausgleichen.

              Grüße
              TS

              1. Ich hoffe, dass das jetzt nicht persönlich gemeint ist, sondern Du damit nur ausdrücken willst, dass Du ausschließlich für eine genau bekannte Client-Schaar verwickelst (sic!). Da kann man dann Fehler auch durch Gegenfehler wieder ausgleichen.

                1. Genau so ist es.
                2. Ich sehe es weder als Fehler noch als Gegenfehler. Genau hierfür hat JS Funktionen, die in ein Feld clientseitig etwas schreiben. Das nutze ich aus. Es ist also mitnichten ein Fehler.
                3. Ich habs mal durchprogrammiert und "it works like a charm"...

                Paul

            2. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

              mein Browser benutzt kein Javascript.

              Das soll ein Problem sein? Dein Browser wird auch meine Software nie! benutzen.

              Wieso nicht?

              Problem ist also hiermit gelöst :)

              Dann ist es zum Glück auch nicht mehr mein Problem.

              Spirituelle Grüße
              Euer Robert
              robert.r@online.de

              --
              Möge der wahre Forumsgeist ewig leben!
              1. Hi,

                Dein Browser wird auch meine Software nie! benutzen.

                Wieso nicht?

                Nicht jede Software ist öffentlich. Und nur mal den Fall gesetzt, dass Du unwahrscheinlicherweise User miener Software wärest, hätte Dein Chef zuvor unterschrieben, in welcher Browserkofiguration Du meine Software zu benutzen hättest.

                Problem ist also hiermit gelöst :)

                Dann ist es zum Glück auch nicht mehr mein Problem.

                Trotzdem danke, dass Du es temporär zu Deinem Problem gemacht und mir zu helfen versucht hast.

                Paul

        2. Hallo und guten Nachmittag,

          Das ist eindeutig ein Designfehler - Fehler im Programmdesign, hat nichts mit bunten Bildern zu tun ;-)

          Ich benutze JS hier genau dafür, wozu es gedacht ist. Ich setze clientseitig in ein DIV einen Wert ein, den ich im Verlauf des Scripts gerneriere/erhalte.

          Ist es wirklich genau dafür gedacht?
          Warum machst Du das nicht schon serverseitig? Dann müsstest Du dich nicht darauf verlassen, dass der Client Javascript bereitstellt!

          Das DIV widerum generiere ich dynamisch, und zwar über eine Funktion.

          Daran ist ja auch ert einmal nichts auszusetzen. Das machen alle CMS irgedwie genauso.

          Wo ist das Problem für Dich?

          Dass Du Probleme an Stellen verlagerst, an denen sie noch weiter wachsen? Wenn der Client kein Javascript unterstützt, funktioniert dein Apparat nicht mehr. Und irgendwie musst Du den einzusetzenden Wert ja ohnehin zum Client transportieren. Warum dann nicht gleich an der passenden Stelle?

          Oder wolltest Du darauf hinaus, dass sich noch nach dem Ausliefern des eigentlichen Dokumentes der Inhalt des speziellen DIVs (mehrfach) ändern soll, ohne dass das Dokument neu geladen werden muss? Dann sind wir aber bei AJAX oder Websockets angelangt und müssten Fragen und Antworten nochmal neu sortieren :-)

          Grüße
          TS

          1. Hi,

            Warum machst Du das nicht schon serverseitig? Dann müsstest Du dich nicht darauf verlassen, dass der Client Javascript bereitstellt!

            Das mache ich im Normalfall serverseitig. Ich könnte es auch hier serverseitig machen, dann müßte ich aber entweder den Zählvorgang doppelt durchführen lassen, ihn zwischenspeichern oder meine (spätere) include-Datei in 2 Dateien splitten. Alle 3 Optionen wären selbstredend locker möglich, würden aber insgesamt mehr Arbeit machen als einfach ein DIV zu generieren, in das der Client per JS einen Eintrag vornimmt. Da eh JQuery mitläuft, macht $('#mydiv').html('Mein Eintrag') das ganz vorzüglich. Und dazu ists auch angedacht.

            Darauf verlassen, das der Client JS bereitstellt, muß ich mich ohnehin. Es geht hier um das Einbinden von OSM Daten über eine JS-Bibliotek. Das ist sozusagen nichts anderes als pures Javascript.

            Das DIV widerum generiere ich dynamisch, und zwar über eine Funktion.

            Daran ist ja auch ert einmal nichts auszusetzen. Das machen alle CMS irgedwie genauso.

            Nicht wahr?...

            Dass Du Probleme an Stellen verlagerst, an denen sie noch weiter wachsen? Wenn der Client kein Javascript unterstützt, funktioniert dein Apparat nicht mehr. Und irgendwie musst Du den einzusetzenden Wert ja ohnehin zum Client transportieren. Warum dann nicht gleich an der passenden Stelle?

            1. Wenn der Client kein JS will oder kann, ist die Funktion dieses Teils meiner Software ohnehin nicht nutzbar. (s.o.)

            2. Im Verlauf des Zeichnens dieser Karte entstehen die Daten. Sie sollten aber oberhalb der Karte als Überschrift stehen. Daher die Optionen:

            3. Einen Teil doppelt ausführen/ggf. zwischenspeichern.

            4. Die Inculde-Datei splitten.

            5. Per JS die Daten clientseitig über die Karte setzen.

            Ich habe mich für Punkt 3 entschieden, weil es mit großem Abstand die wenigste Arbeit macht und das Gesamtkosntrukt der Programmteile unversehrt erhalten bleibt. Bedenke, ich nutze die anderen Programmteile noch in vielen anderen "Modulen"

            Das ist also alles andere als ein Designfehler, insbesondere wenn die Gruppe der Clients bekannt ist und JS in allen (und in diesem Programmteil ganz besonders) zwingende Voraussetzung zur Programmnutzung ist.

            Hier im Forum wird oft vorschnell etwas als Designfehler ausgemacht, was bei näherem Hinsehen nicht so ist.

            Davon abgesehen: Es kann gute Gründe dafür geben, einen vermeintlichen Designfehler zu nutzen, wenn hierdurch ein anderer Nutzen entsteht. Beispiel Datenbank: Es kann vorteilhaft sein, eine begrenzte Anzahl von Daten redundant zu führen (Designfehler, nicht wahr?), wenn sich hierdurch an anderer Stelle ein für das Gesamtprojekt höherer Gesamtnutzen ergibt. Das kann bessere (menschliche) Lesbarkeit im Datenbackend für Supportfälle sein, das kann auch die ein oder andere Query sein, die hierdurch deutlich einfacher und/oder effizienter ist.

            Paul

              1. Wenn der Client kein JS will oder kann, ist die Funktion dieses Teils meiner Software ohnehin nicht nutzbar. (s.o.)

              2. Im Verlauf des Zeichnens dieser Karte entstehen die Daten. Sie sollten aber oberhalb der Karte als Überschrift stehen. Daher die Optionen:

              3. Einen Teil doppelt ausführen/ggf. zwischenspeichern.

              4. Die Inculde-Datei splitten.

              5. Per JS die Daten clientseitig über die Karte setzen.

              Ich habe mich für Punkt 3 entschieden, weil ...

              Obiger Code erscheint beim Schreiben und Zitieren als 1. 2. und dann 1.2.3.

              Im Posting selber aber wird das dann 1.2.3.4.5. durchnummeriert.

              Paul

              P.S: Ich habe mich für Punkt 3. " Per JS die Daten clientseitig über die Karte setzen." entschieden, im Originalpost aber steht, dass ich mich für einen Punkt 3 entschieden hätte, die Daten doppelt zu zählen... das könnte für Verwirrung sorgen durch den Fehler im Forum.

              1. Hallo Paul!!,

                Das ist zwar nicht schön, aber kein Programmierfehler. Jedenfalls nicht im Forum. Siehe wiki/SELFHTML:Forum/Bedienung#geordnete_Listen.

                Bis demnächst
                Matthias

                --
                Signaturen sind bloed (Steel) und Markdown ist mächtig.
                1. Hallo Paul!!,

                  Das ist zwar nicht schön, aber kein Programmierfehler. Jedenfalls nicht im Forum. Siehe wiki/SELFHTML:Forum/Bedienung#geordnete_Listen.

                  Hallo Mathias,

                  Unsinniges Feature. Solche Automatiken nerven schon in vielen anderen Programmen mehr als genug, sind aber dort wenigstens sichtbar.

                  Hier im Forum kommt aber etwas anders raus, als ich als Poster eines Beitrages vermute. Nicht so toll, aber wenn mans weiß, benutzt man eben Listen nicht mehr.

                  Danke für den Hinweis

                  Paul