Pit: Hiddenfield in hidden Formular Wert zuweisen

Hallo,

mir gelingt es grad nicht, einem hiddenfield in einem hidden Formular einen Wert zuzuweisen und ich finde auch grad den Weg zur Lösung des Problems nicht.

<form action=\"$PHP_SELF\" id=\"fDel\" class=\"mF_hide\" method=post accept-charset=utf-8>
<input type=hidden id=TDSQL name=TDSQL value=''>
  1. Schritt: Hier wird ein Fenster geöffnet, das einen Termin editierbar macht
$('.week')
    .on('click', 'img, a, button', function(event) {
    ...
		var TDSQL = arrTID[5] + "-" + arrTID[4] + "-" + arrTID[3];
	  console.log(TDSQL); // hier passt der Wert noch, ein Datum wird ausgegeben
  1. Schritt: Der Termin soll gelöscht werden
$('#mDel').on('click', function(){
 $("#fDel").show(); // blendet das fDel Formular ein
 $('#TDSQL').val(TDSQL); // Variable aus Schritt 1 soll eingesetzt werden

bringt leider nicht den gewünschten Erfolg.

Übermittelt wird "object HTMLInputElement". Was will mir das sagen?

Pit

  1. Übermittelt wird "object HTMLInputElement". Was will mir das sagen?

    Übrigens: Wenn ich einen Striung anstelle der Variablen einsetze, kommt dieser 1:1 am Server an.

    Es scheint also so zu seoin, dass die Variable nicht mehr bekannt ist... ?

    Pit

    1. Hallo Pit,

      Es scheint also so zu sein, dass die Variable nicht mehr bekannt ist... ?

      Richtig erkannt.

      Das ist so, weil du sie im click-Handler für ".week" deklarierst, und im click-Handler für "#mDel" verwenden willst. Das sind zwei verschiedene Scopes.

      Musst Du TDSQL im .week click befüllen? Hast Du arrTID im #mDel click noch zur Verfügung?

      Wenn nicht, musst Du die Variable eine Ebene nach außen legen, oder kannst den Wert als jQuery-Data an #mDel ankleben.

      Rolf

      --
      sumpsi - posui - clusi
      1. Hallo Rolf,

        Das ist so, weil du sie im click-Handler für ".week" deklarierst, und im click-Handler für "#mDel" verwenden willst. Das sind zwei verschiedene Scopes.

        Jaja, sowas habe ich schon befürchtet. Im Sinne von "Geltungsbereich von Variablen", hm?

        Musst Du TDSQL im .week click befüllen? Hast Du arrTID im #mDel click noch zur Verfügung?

        Ja und nein...

        Wenn nicht, musst Du die Variable eine Ebene nach außen legen, oder kannst den Wert als jQuery-Data an #mDel ankleben.

        Danke für die Hilfe, "jQuery-Data an #mDel ankleben" funktioniert einwandfrei.

        Frage: Wie würde denn "die Variable eine Ebene nach außen legen" durchgeführt werden?

        Pit

        1. Hallo Pit,

          Frage: Wie würde denn "die Variable eine Ebene nach außen legen" durchgeführt werden?

          Na, prinzipiell erstmal so:

          var TDSQL;
          
          $('.week')
              .on('click', 'img, a, button', function(event) {
              ...
          		TDSQL = arrTID[5] + "-" + arrTID[4] + "-" + arrTID[3];
          	  console.log(TDSQL); // hier passt der Wert noch, ein Datum wird ausgegeben
          Schritt: Der Termin soll gelöscht werden
          $('#mDel').on('click', function(){
           $("#fDel").show(); // blendet das fDel Formular ein
           $('#TDSQL').val(TDSQL); // Variable aus Schritt 1 soll eingesetzt werden
          

          Ob das in dieser Form auch gemacht werden SOLLTE, hängt davon ab, ob dein Registriercode in einer anderen Funktion gekapselt ist oder nicht. Wenn nicht - dann bleib bei data. Wenn doch, dann kannst Du das so wie gezeigt machen.

          Dieser Code funktioniert, weil JavaScript Closures bildet und darum den Scope aufrufender Funktionen unter gewissen Umständen festhält. Ich gucke mal, ob ich das im Wiki noch etwas ausformulieren kann.

          Rolf

          --
          sumpsi - posui - clusi
          1. Hallo Rolf,

            Dieser Code funktioniert, weil JavaScript Closures bildet und darum den Scope aufrufender Funktionen unter gewissen Umständen festhält. Ich gucke mal, ob ich das im Wiki noch etwas ausformulieren kann.

            Ok, verstehe. Wende ich sogar teilweise an, habe es mir aber noch nie vergegenwärtigt.

            In dem Fall, um den es hier geht, bleibe ich tatsächlich bei data, daher danke für den Tip.

            Noch eine Frage: Bevor ich das Post gestern verfasste, hatte ich mir ja bereits Gedanken um eine Lösung gemacht. Meine Idee war, den Wert aus TDSQL im "week-Tab" (so nenne ich das jeztzt mal) in eine x-beliebiges hidden div als value zu notieren und dann beim onclick-event auf "mDel" den Wert wieder in eine Variable einzulesen, bevor ich den "week-Tab" wieder verstecke und den "Delete-Tab" sichtbar mache.

            Hätte das auch funktioniert?

            Pit

            1. Hallo Pit,

              natürlich hätte das funktioniert. Du hättest damit eine globale Variable gebildet, nur nicht im JavaScript global namespace, sondern im DOM.

              jQuery data liegt ebenfalls im DOM, allerdings nicht sichtbar. jQuery erzeugt einen sogenannten Expando-Key als Property-Name und erweitert das Objekt zum DOM-Element damit um ein Property. Der Wert des Property ist ein leeres Object, in dem die mit data("foo", "bar") gesetzten Key-Value Paare abgelegt werden. Wird das Element gelöscht, verdampft auch das Expando-Property.

              Rolf

              --
              sumpsi - posui - clusi
  2. Hallo Pit,

    <form action=\"$PHP_SELF\" id=\"fDel\" class=\"mF_hide\" method=post accept-charset=utf-8>
    <input type=hidden id=TDSQL name=TDSQL value=''>
    

    Das hat zwar mit deinem Problem nichts zu tun, aber du verwendest drei verschiedene Schreibweisen für die Attribut-Wert-Paare. Damit machst du dir die Fehlersuche selbst schwer.

    Bis demnächst
    Matthias

    --
    Rosen sind rot.
    1. Hallo Matthias, hallo Pit,

      das sieht aus, als würde das form per php echo ausgegeben; das erklärt das Escaping. Wenn für das erzeugte HTML konsequent einfache statt doppelte Anführungszeichen verwendet würden, könnte man die Backslasherei schon mal vermeiden. Es ist auch sinnvoll, Attributwerte grundsätzlich in Anführungszeichen zu setzen (es ist in HTML zwar nicht (immer) Pflicht, aber trotzdem guter Stil). Ich hätte ja gedacht, dass sowas auch hier stehen würde, steht da aber nicht. Frage an die Wiki-Überblickhaber: gehört das da hin (ein I anbiet)?

      Eine Alternative wäre, den PHP-Modus zu beenden und das Form als HTML auszugeben:

      ?>
      <form action='<?= $PHP_SELF?>' id='fDel' class='mF_hide' method='post' accept-charset='utf-8'>
         <input type='hidden' id='TDSQL' name='TDSQL' value=''>
      ...
      </form>
      <?php
      

      Rolf

      --
      sumpsi - posui - clusi
      1. Hallo Rolf B,

        Frage an die Wiki-Überblickhaber: gehört das da hin (ein I anbiet)?

        Klar. Warum nicht, auch wenn man ein Einstiegskapitel nicht überfrachten sollte. Es gibt http://wiki.selfhtml.org/wiki/HTML/Regeln/Guter_HTML-Stil Vielleicht reicht auch ein Link.

        Eine Alternative wäre, den PHP-Modus zu beenden und das Form als HTML auszugeben:

        Ja, so würde ich das auch machen.

        Bis demnächst
        Matthias

        --
        Rosen sind rot.
      2. Tach!

        <form action='<?= $PHP_SELF?>' id='fDel' class='mF_hide' method='post' accept-charset='utf-8'>
           <input type='hidden' id='TDSQL' name='TDSQL' value=''>
        

        a) Gibt es $PHP_SELF in dieser nackigen Form? Warum steht das da nicht als $_SERVER['PHP_SELF']?

        b) Da fehlt die kontextgerechte Behandling. Ein htmlspecialchars() muss sein, sonst gibts da eine XSS-Lücke. Und damit man htmlspecialchars ohne zusätzliches ENT_QUOTES aufrufen kann, sollte der action-Wert in doppelte Anführungszeichen gesetzt werden.

        dedlfix.

      3. @Rolf B

        Eine Alternative wäre, den PHP-Modus zu beenden und das Form als HTML auszugeben:

        Eine noch bessere Alternative wäre, Code und HTML strikt voneinander zu trennen.

        MfG

        1. Tach!

          Eine Alternative wäre, den PHP-Modus zu beenden und das Form als HTML auszugeben:

          Eine noch bessere Alternative wäre, Code und HTML strikt voneinander zu trennen.

          So viel besser ist das gar nicht. Wenn man in einer Template-Engine Blöcke für Wiederholungen und bedingte Ausgaben definiert, dann ist das auch Code. Eine verbreitete Vorgehensweise ist stattdessen, Logiken zu trennen. Die Geschäftslogik verarbeitet die Daten und stellt die für die Ausgabe benötigten Daten bereit. Die Ausgabelogik erzeugt daraus die Ausgabe und verwendet dazu den Code, der für Wiederholungen, bedingte Ausgaben, Werteformatierungen und auch Maskierungen benötigt wird.

          dedlfix.

          1. Tach!

            Eine Alternative wäre, den PHP-Modus zu beenden und das Form als HTML auszugeben:

            Eine noch bessere Alternative wäre, Code und HTML strikt voneinander zu trennen.

            So viel besser ist das gar nicht. Wenn man in einer Template-Engine Blöcke für Wiederholungen und bedingte Ausgaben definiert, dann ist das auch Code.

            Nein. Platzhalter sind eben kein Code! Es gibt zwar Konstrukte für Loops und Boolsche Verwendung aber Code ist das noch lange nicht.

            Und hinsichtlich der sich hier zeigenden Problematik ist das im Übrigen völlig uninteressant.

            MfG

            1. Tach!

              Nein. Platzhalter sind eben kein Code! Es gibt zwar Konstrukte für Loops und Boolsche Verwendung aber Code ist das noch lange nicht.

              Deklarativer Code ist auch Code.

              dedlfix.

            2. Hallo pl,

              Und hinsichtlich der sich hier zeigenden Problematik ist das im Übrigen völlig uninteressant.

              Ja. Hat Matthias eingangs dieses Astes ja auch gleich gesagt :) Aber off-topics führen gern zu interessanten Fachgesprächen im Fachforum.

              Eine TE ist ein Vehikel, um in der Anwendung Schichtentrennung herbeizuführen. Jede TE definiert irgendeine Syntax zum Einsteuern von Daten, die meisten auch Zusatzsyntax für weitere Operationen, wodurch eine formale Sprache gebildet wird. Es ist relativ egal, ob diese formale Sprache "Smarty" heißt, "PL Template Language", Perl oder PHP. Der Vorteil einer "nicht-Programmiersprache" in der UI-Schicht liegt darin, dass man nicht dazu verleitet wird, dort Business-Logik zu programmieren. Ich kann meine UI-Templates auch rein mit PHP bilden (was Smarty zum Beispiel unter der Haube tut, es transpiliert Smarty-Templates in PHP). Der Vorteil von Template-Sprachen ist auch, dass die für's Template wichtigen Operationen knackig und ausdrucksstark definiert werden können; in einer Universalsprache formulierte Templates sind da umständlicher.

              Ja, und weil es Template-Nutzern auf den Keks geht, wenn die TE nur Variablen auflöst und man Code-behind braucht, der die Business-Schicht mit GUI-spezifischem Code vermüllt (bzw. man eine Extra-Schicht zwischen GUI und Business-Schicht einziehen muss, um ein ViewModel aufzubauen), sind in viele TE so viele Möglichkeiten zum Codieren eingesickert, dass sie genauso Turing-vollständig sind wie die Host-Sprache. Sobald ich in einer formalen Sprache die Elemente "sequenz", "alternative" und "iteration" habe, dazu noch die Möglichkeit, irgendwie Werte zu speichern, ist sie Turing-vollständig. Wie hält es deine TE mit Turing?

              Und es ward Code!

              Rolf

              --
              sumpsi - posui - clusi