Rikarda: DIV-Inhalt mit Datenbankeinträgen per Zufall

Hallo Ihr Lieben,

bisher lade ich per Zufall aus meiner MySQL-DB einen Eintrag, die Seite lädt sich über einen META-Befehl alle 20 Sekunden neu.

Dies würde ich gerne ohne komplettes Neuladen der Seite realisieren.

Könnt Ihr mir sagen, wie ich die Inhalte aus der DB neu lade, die komplette Seite aber stehen bleib. Es soll sich nur der Inhalt des DIVs ändern.

Danke und liebste Grüße,

Eure Rikarda

  1. Hallo!

    Könnt Ihr mir sagen, wie ich die Inhalte aus der DB neu lade, die komplette Seite aber stehen bleib. Es soll sich nur der Inhalt des DIVs ändern.

    Stichwort AJAX. Mit dem jQuery-Framework ist es z.B. ziemlich einfach.

    Grüße, Matze

    1. Stichwort AJAX. Mit dem jQuery-Framework ist es z.B. ziemlich einfach.

      "Mitohne" dem jQuery-Framework-Geschwuchtel ist es auch einfach.
      Vergleiche: 20 Zeilen gegen ein ganzes Framework.

      function getMyHttpResponseText (str_querry) {  
        xmlHttp = new XMLHttpRequest;  
        if (xmlHttp) {  
          xmlHttp.open('GET', 'beispiel.php?q=' + encode(str_querry), true);  
          xmlHttp.onreadystatechange = function () {  
            if (xmlHttp.readyState == 4) {  
              //  
              WasImmerDuWillst(xmlHttp.responseText);  
              //  
           }  
        };  
         xmlHttp.send(null);  
      } else {  
         alert ('[link:http://de.wikipedia.org/wiki/XMLHttpRequest@title=Nö! Mit IE 5 oder 6 will ich nicht mehr]')  
      }  
        
      function WasImmerDuWillst(str) {  
          tuDies();  
          tuDas();  
          tuJenes();  
      }  
      
      

      Jörg Reinholz

      1. Hallo!

        "Mitohne" dem jQuery-Framework-Geschwuchtel ist es auch einfach.
        Vergleiche: 20 Zeilen gegen ein ganzes Framework.

        jQuery ist mittlerweile modular. Man muss nicht mehr den gesamten unnötigen Ballast mit an Bord nehmen. Und für jemanden der sich damit nicht auskennt, davon gehe ich mal aus, sonst hätte der OP nicht so eine Frage gestellt, ist es mit framework allemal einfacher als das Konstrukt selbst zu schreiben.
        ...oder das Beispiel von dir zu übernehmen und anzupassen.

        Grüße, Matze

      2. Stichwort AJAX. Mit dem jQuery-Framework ist es z.B. ziemlich einfach.

        "Mitohne" dem jQuery-Framework-Geschwuchtel ist es auch einfach.
        Vergleiche: 20 Zeilen gegen ein ganzes Framework.

        Ich würde trotzdem jquery vorziehen.

        Mfg entropie

        --
        Whenever people agree with me I always feel I must be wrong.
          -- Oscar Wilde
      3. Hi,

        Stichwort AJAX. Mit dem jQuery-Framework ist es z.B. ziemlich einfach.

        "Mitohne" dem jQuery-Framework-Geschwuchtel ist es auch einfach.
        Vergleiche: 20 Zeilen gegen ein ganzes Framework.

        man will nur selten "nur" einen AJAX-Request senden. Und dann implementiert man eben das nächste "kleine bisschen" uswusf, bis man große Teile eines Frameworks nachgebaut hat inkl. hunderter neuer Bugs.

        Abgesehen von der Tatsache, dass dein Code furchtbar schlecht zu testen ist und quasi gar nicht wiederverwendbar. Als Gegenbeispiel mal ein Beispiel mit dem Angular-Framework, was m.E. gut zu lesen ist:

        HTML:

        <!doctype html>  
        <html>  
            <head>  
                <meta charset="utf-8"  
                <title></title>  
            </head>  
            <body ng-app="MyModule" ng-controller='RandomTextController'>  
          
                {{ randomText }}  
          
                <output ng-hide="! error">{{ error }}</output>  
          
                <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.0.5/angular.min.js"></script>  
                <script src="scripts/main.js"></script>  
            </body>  
        </html>  
        
        

        JavaScript:

          
        var app = angular.module('MyModule', []);  
        function RandomTextController($scope, backendService, $window) {  
        	$scope.randomText = '';  
        	$scope.error = undefined;  
        	loadText();  
        	$window.setInterval(loadText, 2000);  
          
        	function loadText() {  
        		backendService.getRandomText().then(function(data) {  
        			$scope.randomText = data.data;  
        		}, function(err) {  
        			$scope.error = err;  
        		});  
        	}  
          
        }  
        RandomTextController.$inject = ['$scope', 'backendService', '$window'];  
        app.controller('RandomTextController', RandomTextController);  
          
        app.factory('backendService', ['$http', function($http) {  
        	return {  
        		getRandomText : function() {  
          			return $http.get('/randomText.php')  
        		}  
        	};  
        }]);  
        
        

        Man sollte sich nicht von der Länge täuschen lassen. Es ist länger, weil ich das Model ($scope in RandomTextController) und die Art und Weise, wie man die Zufallstexte abfragt, voneinander getrennt habe.

        In den Service "backendService" kann man beliebig weitere Services hineintun, und mit Dependency Injection kann man diesen Service bequem in eigene Controller einfügen. Weiterhin kann man ohne weiteres zum Testen einen Mock-backendService einführen, welcher keinen HTTP-Requests macht.

        Bis die Tage,
        Matti

      4. Hallo Jörg,

        Vergleiche: 20 Zeilen gegen ein ganzes Framework.

        diese Variante würde mir ehrlich gesagt besser gefallen.

        Möchte das Ganze dann mit

        document.getElementById("prev").innerHTML = 'Beispieltext';

        aktualisieren lassen.

        Kannst Du mir sagen, wie ich das dann anpasse, so dass die Aktualisierung alle 25 Sekunden erfolgt?

        Ganz lieben Dank und schöne Träume :-)

        Rikarda

        1. Zu Deiner Frage:

          <script type="text/javascript">  
            
          var wiederhole;  
            
          function holeDaten() {  
            xmlHttp = new XMLHttpRequest;  
            if (xmlHttp) {  
              xmlHttp.open('GET', 'getText.php', true);  
              xmlHttp.onreadystatechange = function () {  
                if (xmlHttp.readyState == 4) {  
                  // schreiben:  
                  document.getElementById("prev").innerHTML=xmlHttp.responseText  
                  // wiederholen  
                  wiederhole=window.setTimeout(" holeDaten()", 25000);  
               }  
            };  
             xmlHttp.send(null);  
          }  
          <script>
          

          getText.php ist das Skript, welches die Daten liefert. Du musst es nur einmal starten
          (z.b. mit

          <body onload="holeDaten()">

          Nachdem das Skript die empfangenen Daten an der von Dir gwünschten Stelle eingetragen hat wird der Browser es durch das
          window.setTimeout("holeDaten()", 25000); 25 Sekunden später wieder starten.

          Beispiel:

          <?php #getText.php  
          print date('Y-m-d H:i:s');  
          ?>
          

          würde die Uhrzeit liefern.

          Übrigens ein Aufhören kann man  auch veranlassen:

          <input type="button"  value="Stop" onclick="window.clearTimeout(wiederhole);" />

          Nur dazu ist übrigens die Variable 'wiederhole' notwendig und muss dazu auch außerhalb der Funktion angelegt werden.

          Mehr dazu:

          http://de.selfhtml.org/javascript/objekte/window.htm#set_timeout@title=http://de.selfhtml.org/javascript/objekte/window.htm#set_timeout

          Ganz lieben Dank

          Bitte.

          und schöne Träume :-)
          "Eine Welt ohne Miesepeter ... Hach, das wär was!"

          Jörg Reinholz

          1. wiederhole=window.setTimeout(" holeDaten()", 25000);

            wiederhole=window.setTimeout("holeDaten()", 25000);

            Sorry. Ein Leerzeichen zu viel.

            Jörg Reinholz, Genauheim

          2. Lieber Jörg,

            danke für Deine schnelle Antwort.

            xmlHttp.open('GET', 'getText.php', true);

            OK, hier gebe ich das PHP-Skript an, welches die Einträge aus der DB holt.
            Es handel sich dabei um einen Titel, einen Text und eine Quelle, d.h. also 3 Angaben.
            Kann ich die irgendwie trennen?

            document.getElementById("prev").innerHTML=xmlHttp.responseText

            Ist "xmlHttp.responseText" all das, was getText.php ausgibt an reinen Zeichen?

            Ich bräuchte dann sowas wie

            document.getElementById("prevTitel").innerHTML=xmlHttp.responseText[1]
            document.getElementById("prevText").innerHTML=xmlHttp.responseText[2]
            document.getElementById("prevQuelle").innerHTML=xmlHttp.responseText[3]

            Mmmh. Das ist wohl nicht so einfach, jedenfalls nicht für mich :-(

            Viele Grüße und schonmal 1000 Dank!

            Rikarda

            1. OK, hier gebe ich das PHP-Skript an, welches die Einträge aus der DB holt.

              .. und baust die HTML-Ausgabe für die Anzeige fertig zusammen.

              Das wars dann scho ;-)

              Gruß Rainer

              1. Hallo Rainer

                .. und baust die HTML-Ausgabe für die Anzeige fertig zusammen.

                stimmt. Hätte ich auch selbst drauf kommen können. Klappt auch prima!

                Allerdings werden jetzt Sonderzeichen (ä,ü, ...) nur noch als Fragezeichen angezeigt - wie passe ich das noch an?

                Ach ja, hast Du ne Idee wie ich mit der Abfrage

                SELECT * FROM  tabelle ORDER BY prioritaet*RAND() Limit 0,1

                vermeide, dass zwei aufeinander folgende Ausgaben gleich sind - es gibt Einträge mit der gleichen Priorität.

                Hatte das beim Meta-Refresh mit der Übergabe der aktuell aufgerufenen ID gemacht und dann die Abfrage so:

                SELECT * FROM  tabelle WHERE id != '".$_GET['idcheck']."' ORDER BY prioritaet*RAND() Limit 0,1

                Geht das auch einfacher?

                LG, Rikarda

                1. Hallo,

                  .. und baust die HTML-Ausgabe für die Anzeige fertig zusammen.
                  stimmt. Hätte ich auch selbst drauf kommen können. Klappt auch prima!
                  Allerdings werden jetzt Sonderzeichen (ä,ü, ...) nur noch als Fragezeichen angezeigt - wie passe ich das noch an?

                  oha, du hast also auch noch ein Problem mit der Zeichencodierung.
                  Vermutlich gibt dein PHP-Script den Text in irgendeiner ISO-Codierung aus (wahrscheinlich ISO-8859-1), das XHR-Objekt erwartet aber UTF-8.

                  Saubere Lösung: Stelle deine Datenquelle komplett auf UTF-8 um - also das liefernde Script, aber vor allem auch die in der DB gespeicherten Werte. Das schließt theoretisch die Umcodierung aller DB-Einträge ein.
                  Viel Aufwand, viele Fehlerquellen.

                  Quick&Dirty-Lösung: Codiere im PHP-Script den Text mit utf8_encode() um, bevor du ihn an den Browser ausgibst.

                  So long,
                   Martin

                  --
                  "Mutti, hier steht, das Theater sucht Statisten. Was sind Statisten?" - "Das sind Leute, die nur rumstehen und nichts zu sagen haben." - "So wie Papa?"
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                  1. oha, du hast also auch noch ein Problem mit der Zeichencodierung.

                    Hab jetzt in der Datei

                    header('Content-Type: text/html; charset=iso-8859-1');

                    hinzugefügt und es klappt prima.

                    Umstellen auf utf8 ist natürlich sauberer, aber so ists erstmal einfacher.

                    Danke!

                2. Allerdings werden jetzt Sonderzeichen (ä,ü, ...) nur noch als Fragezeichen angezeigt - wie passe ich das noch an?

                  Du willst der Rückgabe einen passenden Content-header voranstellen. Das kann etwas sein wie

                  <?php
                  header ('Content-Type: text/html; charset=utf-8');

                  Achte darauf, dass die HTML-Seite, das PHP-Skript, die Datenbank und auch die Kommunikation zwischen PHP <-> Datenbank die gleiche Kodierung verwendet.

                  Es muss nicht UTF-8 sein...

                  Hatte das beim Meta-Refresh mit der Übergabe der aktuell aufgerufenen ID gemacht und dann die Abfrage so:

                  SELECT * FROM  tabelle WHERE id != '".$_GET['idcheck']."' ORDER BY prioritaet*RAND() Limit 0,1

                  Geht das auch einfacher?

                  Definiere 'einfacher'. Es gibt zahlreiche Möglichkeiten. Speichere die letzte ID in einem Cookie, einer Session oder übergib diese als get-Parameter

                  Hier mit Cookie:

                  Erst prüfst Du, ob das Cookie da ist und setzt es ggf. auf -1 (gibt es in der Datenbank nicht)
                  if (! isset($_COOKIE['lastSnipplet']) ) {
                      $_COOKIE['lastSnipplet']=-1;
                  }
                  ...
                  // 'SELECT * FROM  tabelle WHERE id != ' . intval($_COOKIE['lastSnipplet']) .' ORDER BY prioritaet*RAND() Limit 0,1'

                  Warum SELECT *? Das ist "nicht so toll". Gib die Spaltennamen an, das macht das Proggen auch für dich übersichtlicher!

                  Dein Orginal hat ein erhebliches Sicherheitsproblem, weil Du die Daten aus $_GET ungeprüft übernommen hast. Damit hat ein Angreifer "hübsche" Möglichkeiten

                  Falls Du die Rückgaben aus der DB nach $row auflöst und das als assoziativen Array bauen lässt:

                  setcookie('lastSnipplet',row['id'])

                  Damit steht beim nächsten Aufruf in $_COOKIE['lastSnipplet'] die ID des letzten Datensatzes, der dem Client gesendet wurde.

                  Das gänge freilich auch mit GET-Parameter, Javascript und dem Beispiel mit json.

                  <?php #getTexteAsJSON.php  
                  $ausg['titel']='Das ist ein toller Titel';  
                  $ausg['text']='Das ist ein toller Text';  
                  $ausg['quelle']='geklaut von <a href="http://bauer.ro/geschichte_vom_kuerbis.html">rumänischem Bauer</a>';  
                  $ausg['lastSnipplet'] = $id; (aus der Datenbank)  
                    
                  header('Content-Type:text/html; charset=UTF-8');  
                  print json_encode($ausg);  
                  ?>
                  
                  <script type="text/javascript">  
                    
                  var wiederhole; // für das Anhalten  
                  var lastSnipplet=-1; //Speicher für das letzte abgeholte Snipplet  
                    
                  function holeDaten() {  
                    xmlHttp = new XMLHttpRequest;  
                    if (xmlHttp) {  
                      xmlHttp.open('GET', 'getTextAsJSON.php?lastSnipplet=' + lastSnipplet, true);  
                      xmlHttp.onreadystatechange = function () {  
                        if (xmlHttp.readyState == 4) {  
                    
                          //auswerten, erzeugt assoziativen Array  
                          eval('data='+xmlHttp.responseText);  
                    
                          // schreiben:  
                          document.getElementById('titel').innerHTML=data['titel'];  
                          document.getElementById('text').innerHTML=data['text'];  
                          document.getElementById('quelle').innerHTML=data['quelle'];  
                          // letztes Sniplet speichern:  
                          lastSnipplet=data['lastSnipplet'];  
                    
                    
                          // wiederholen  
                          wiederhole=window.setTimeout("holeDaten()", 25000);  
                       }  
                    };  
                     xmlHttp.send(null);  
                  }  
                  </script>
                  

                  Jörg Reinholz

                  1. Hallo,

                    Du willst der Rückgabe einen passenden Content-header voranstellen. [...]

                    <?php #getTexteAsJSON.php
                    $ausg['titel']='Das ist ein toller Titel';
                    $ausg['text']='Das ist ein toller Text';
                    $ausg['quelle']='geklaut von <a href="http://bauer.ro/geschichte_vom_kuerbis.html">rumänischem Bauer</a>';
                    $ausg['lastSnipplet'] = $id; (aus der Datenbank)

                    header('Content-Type:text/html; charset=UTF-8');
                    print json_encode($ausg);
                    ?>

                    Widersprichst du dir hier nicht selbst?
                    Man müsste doch JSON mit Content-Type:application/json; charset=UTF-8 ausliefern.

                    Jörg Reinholz

                    martachen

                    1. Man müsste doch JSON mit Content-Type:application/json; charset=UTF-8 ausliefern.

                      Ja, das wäre superextraspezialhyper-korrekt. Aber ersetze "müsste" durch "sollte". Schließlich wird der Content-Type nicht ausgewertet und die Rückgabe seitens des Skriptes als Text betrachtet.

                      Guggst Du hier:

                      xmlHttp.responseText  // <- Da steht "Text"

                      Ich habe das extra für Dich probiert: Zum Glück klappt die Auswertung mindestens mit aktuellem Chromium und Firefox auch bei dem von Dir angegebenen Content-Type - der nicht ausweist, dass da Text kommt.

                      Widersprichst du dir hier nicht selbst?

                      Nein, es ging in der Sache nur um die Kodierung.

                      Jörg Reinholz

                      1. Hi,

                        Man müsste doch JSON mit Content-Type:application/json; charset=UTF-8 ausliefern.

                        Ja, das wäre superextraspezialhyper-korrekt. Aber ersetze "müsste" durch "sollte". Schließlich wird der Content-Type nicht ausgewertet und die Rückgabe seitens des Skriptes als Text betrachtet.

                        Es gibt aber HTTP-Clients, die das auswerten. Z.B. eben jQuery. Einem registriertem success-Handler wird im Falle eines "application/json"-Requests das geparste Objekt übergeben, bei anderen Content-Types eben nur der reine Text (den man dann noch selber parsen muss).

                        Wenn man aber sowieso dabei ist, eine serverseitige Schnittstelle zu bauen, dann sollte man es auch korrekt machen. Und das fällt IMHO nicht mehr unter "superextraspezialhyper-korrekt".

                        Bis die Tage,
                        Matti

                  2. Hi,

                    eval('data='+xmlHttp.responseText);

                    ich hielte es für sinnvoll, dass du über die Sicherheitsimplikationen dieser Zeile berichtest.
                    Ansonsten einfach eine beliebige JSON-Bibliothek (präferiert natives JSON.parse) nutzen.

                    Bis die Tage,
                    Matti

                    1. ich hielte es für sinnvoll, dass du über die Sicherheitsimplikationen dieser Zeile berichtest.

                      Also, wenn das sendende Skript, das auf dem selben Server liegt wie die Ressource in der das Javascript verwendet wird, dann hat derjenige, dessen Server hier Mist sendet, ganz gewiss kein Problem mit dem Javascript, sondern damit, dass ein böswilliger Dritter dort überhaupt Dateien oder Daten (Hier: In der Datenbank) verändern kann.

                      Mithin: Kann der das sendende PHP-Skript ändern, so kann er sehr wahrscheinlich auch die Datei ändern, die den xmlHttp-Request auslöst. Ergo auch das Javascript selbst.

                      Du kannst ja mal versuchen, einen Angriff zu beschreiben, bei dem er das nicht müsste. Bedenke dabei, dass der Inhalt der Datentabelle nicht "User-Generated-Content" ist.

                      Dann müsste ohnehin etwas gemacht werden, das sollte aber auf der Serverseite geschehen und zwar bevor er JSON-String gebaut wird.

                      Zu Deiner anderen Ausführung: Wenn ich jQuery gar nicht erst benutze - also gar nicht erst lade - warum sollte ich dann berücksichtigen, dass jQery dieses oder jenes mit den Daten aus  xmlHttp.responceHeaders (kennt der aktuelle Firefox nicht mal) versucht?

                      Wenn ich einen Baumstamm den Bach runter haben möchte, dann schmeiße ich den da rein. Ich komme nicht mal auf die Idee, den Bach 15m tief und 90m breit auszubaggern, einen Hafen zu bauen und dann einen Hochseedampfer mit dem einen Baumstamm zu beladen, der auch 40m hohen Wellen standhalten kann. Falls es die jemals in dem Bach gibt, dann ist nämlich auch die Sägemühle weg. Mitsamts dem Dorf.

                      Apopros Dorf:

                      Darin wollen wir - bitte - die Kirche lassen. Genau deshalb lehne ich die Verwendung von jQuery ab, wenn es, wie vorliegend, nur darum geht, ein wenig im Dokument "herumzupoken".

                      Apopros Wiederverwendbarkeit des Codes:

                      Mehr als 99% aller Websites beinhalten nur wenige Funktionen, die sich wie vorliegend mit nativen Java-Skript leicht und performant erledigen lassen. Aus der Frage kann ich sehr bestimmt vermuten, dass diese Seite dazu gehören wird. Diese Webseiten haben (im wesentlichen) oft auch 5 bis 10 Jahre Bestand. Wieso sollte, wenn es sehr viel einfacher und sehr viel billiger geht, denn ein Wahnsinns-Aufwand getrieben werden, etliche - nicht selbst beherrschbare Fehlerquellen (Bugs in den Bibliotheken) - "nachgerüstet" werden, um irgendwelchen schönen Theorien zu genügen, z.B. den Code "wiederverwendbar" zu machen -  wenn bis dahin womöglich der Stand der Technik ein ganz anderer ist?

                      Schreibst Du Deine Skripte denn mit einer Textverabeitung, weil Du die dann so schön als PDF exportieren kannst - die nachträglich gezippt schließlich auch nur wenig Platz auf der Platte brauchen?

                      Hilf lieber denen, die den Aufwand mit jQuery treiben (müssen) und dadurch Probleme haben, welche diese ohne das nicht hätten.

                      Jörg Reinholz

                      1. Hi,

                        ich hielte es für sinnvoll, dass du über die Sicherheitsimplikationen dieser Zeile berichtest.

                        Also, wenn das sendende Skript, das auf dem selben Server liegt wie die Ressource in der das Javascript verwendet wird, dann hat derjenige, dessen Server hier Mist sendet, ganz gewiss kein Problem mit dem Javascript, sondern damit, dass ein böswilliger Dritter dort überhaupt Dateien oder Daten (Hier: In der Datenbank) verändern kann.

                        Mithin: Kann der das sendende PHP-Skript ändern, so kann er sehr wahrscheinlich auch die Datei ändern, die den xmlHttp-Request auslöst. Ergo auch das Javascript selbst.

                        Du kannst ja mal versuchen, einen Angriff zu beschreiben, bei dem er das nicht müsste. Bedenke dabei, dass der Inhalt der Datentabelle nicht "User-Generated-Content" ist.

                        Ich könnte mich einfach auf den Standpunkt zurückziehen, dass der OP eben nicht beschrieben hat, woher die Daten kommen. Aber das wäre mir zu kurz gesprungen.

                        Mir ist es wichtig, dass klar ist, dass zwischen Server- und Clientseite eine Schnittstelle gebaut wird. Das Interessante dabei ist, dass es einfach möglich sein sollte, Server- und Clientseite "beliebig" austauschen zu können, d.h. lose zu koppeln (auch wenn der Begriff für etwas anderes verwendet wird). Dies erreicht man am Einfachsten, wenn man beim Entwickeln einer Komponente nur noch das Interface, mit dem man kommuniziert, und nicht die konkrete Implementierung vorstellt.

                        In diesem Fall würde man serverseitig darauf achten, es so zu implementieren, dass unnötige Beschränkungen vermieden werden. Ich habe bereits dass jQuery/Content-Type-Beispiel gebracht, also brauche ich es nicht zu wiederholen. Ein falscher Content-Type ist eine unnötige Beschränkung.

                        Clientseitig würde ich es so implementieren wollen, dass ich bei einem HTTP-GET-Request auf eine bestimmte URL einen String zurückbekomme, den ich als JSON parsen könnte. Es muss ja nicht der eigene Dienst sein, den man anspricht. Und sobald man diese Einsicht hat, sieht man, dass das, was als JSON erwartet wird, nicht mehr unbedingt JSON sein muss ... "user generated content" hin oder her.

                        BTW hat es weniger mit user generated content zu tun… Wenn die Serverseite mit json_encode die Daten kodiert, habe ich danach auf jeden Fall gültiges JSON, den ich auch ohne Sicherheitslücke durch eval schicken darf. Man bräuchte zum Ausnutzen des eval-Konstrukts also eingebettetes JavaScript ("user generated") und eine nicht kontext-gerechte Maskierung (kein json_encode).

                        Zu Deiner anderen Ausführung: Wenn ich jQuery gar nicht erst benutze - also gar nicht erst lade - warum sollte ich dann berücksichtigen, dass jQery dieses oder jenes mit den Daten aus  xmlHttp.responceHeaders (kennt der aktuelle Firefox nicht mal) versucht?

                        Weil die Serverseite unabhängig von der Clientseite ist. Im wesentlichen beschreibt die Serverseite einen Webservice: den "GibMirEinenZufallsText"-Service. Und den willst du vielleicht nicht nur alleine nutzen.

                        Apopros Wiederverwendbarkeit des Codes:

                        Mehr als 99% aller Websites beinhalten nur wenige Funktionen, die sich wie vorliegend mit nativen Java-Skript leicht und performant erledigen lassen. Aus der Frage kann ich sehr bestimmt vermuten, dass diese Seite dazu gehören wird. Diese Webseiten haben (im wesentlichen) oft auch 5 bis 10 Jahre Bestand. Wieso sollte, wenn es sehr viel einfacher und sehr viel billiger geht, denn ein Wahnsinns-Aufwand getrieben werden, etliche - nicht selbst beherrschbare Fehlerquellen (Bugs in den Bibliotheken) - "nachgerüstet" werden, um irgendwelchen schönen Theorien zu genügen, z.B. den Code "wiederverwendbar" zu machen -  wenn bis dahin womöglich der Stand der Technik ein ganz anderer ist?

                        Zum Einen wird die Wahrscheinlichkeit, selber einen Bug zu produzieren, höher sein, als einen in einem Framework zu finden. "Einfacher" und "Billiger" ist selbst geschriebener Code nun auch nicht.
                        $.get('meineUrl', function(meinGeparstesObjekt) { }); erscheint mir schon sehr kompakt und kann man hinschreiben, ohne lang nach der korrekten Schreibweise von XmlHttpRequest zu suchen. CDNs bewirken, dass User auch jQuery nicht noch groß laden müssen, und man hat automatisch Bugfixes zu seiner gewählten Version.

                        Wiederverwendbarkeit bezieht sich aber auch nicht nur auf einen selber... vielleicht findet sich ja jemand anderes, der deinen Service nutzen will. Wir befinden uns ja schließlich im World Wide Web, da ist das "einfach so" möglich. Und selbst wenn man es nur ganz alleine nutzt... irgendwann will der OP vielleicht seinen Client-Code umorganisieren, und dann hilft es, sich möglichst früh Gedanken gemacht zu haben, wie es vernünftig funktionieren kann.

                        Schreibst Du Deine Skripte denn mit einer Textverabeitung, weil Du die dann so schön als PDF exportieren kannst - die nachträglich gezippt schließlich auch nur wenig Platz auf der Platte brauchen?

                        Die Analogie verstehe ich nicht.

                        Bis die Tage,
                        Matti

                        1. Zum Einen wird die Wahrscheinlichkeit, selber einen Bug zu produzieren, höher sein, als einen in einem Framework zu finden.

                          Ich bitte Dich!

                          In den zwanzig Zeilen können sich wohl kaum Bugs verstecken, die nicht zu einer sofort offensichtlichen Disfunktion führen.

                          Weil die Serverseite unabhängig von der Clientseite ist.

                          Ist Sie vorliegend nicht. Client und Server gehören hier zu einem Miniprojekt und mit einem Blick wird sichtbar, was die treiben.

                          vielleicht findet sich ja jemand anderes, der deinen Service nutzen will

                          Hehe. Zufallstext aus der Datenbank eines Dritten? Klingt nicht so, als würde das irgendeinen Sinn ergeben.

                          Falls Du meinst, der würde ja den Text aus einer anderen Datenquelle (verschiedene Datenbanken, Dateien etc. pp.) haben wollen, dann fange ich gewiss nicht damit an, eine Riesen-Wulst an Abtraktions-Schichten und Blackboxen namens "Frameworks" um diese kleine Aufgabe zu bauen, damit alles schön teuer und langsam wird, aber dem Auge des Betrachters auf dem Elfenbeinturm genügt. Allein die Planung frisst dann schon mehr Zeit...

                          Die Analogie verstehe ich nicht.

                          Versuchs einfach.

                          Ein falscher Content-Type ist eine unnötige Beschränkung.

                          Dieses Skript erfüllt genau eine einfache Aufgabe unter Bedingungen, die über die Lebenszeit der Webseite (sehr wahrscheinlich) konstant bleiben. Wozu - bitte - sollte es universeller, in Entwicklung und Betrieb teurer und dafür auch noch schön langsam und Ressourcen fressend werden?

                          "Einfach" ist bei einfachen Sachen einfach besser.

                          Jörg Reinholz

            2. Hallo,

              document.getElementById("prevTitel").innerHTML=xmlHttp.responseText[1]
              document.getElementById("prevText").innerHTML=xmlHttp.responseText[2]
              document.getElementById("prevQuelle").innerHTML=xmlHttp.responseText[3]

              Nicht zwingend! Du kannst auch alle Paramter sammeln und dann auf einmal übergeben. Den Rückgabetext splittest Du auf und verteilst das dann wieder auf deine Elemente. Das hängt von den Verabeitungsmöglichkeiten deiner getText.php ab.

              Viele Grüße
              Siri

            3. OK, hier gebe ich das PHP-Skript an, welches die Einträge aus der DB holt.
              Es handel sich dabei um einen Titel, einen Text und eine Quelle, d.h. also 3 Angaben.
              Kann ich die irgendwie trennen?

              Klar doch! Am universellsten ist das mit JSON :

              <?php #getTexteAsJSON.php
              $ausg['titel']='Das ist ein toller Titel';
              $ausg['text']='Das ist ein toller Text';
              $ausg['quelle']='geklaut von <a href="http://bauer.ro/geschichte_vom_kuerbis.html">rumänischem Bauer</a>';

              print json_encode($ausg);
              ?>

              <script type="text/javascript">

              var wiederhole;

              function holeDaten() {
                xmlHttp = new XMLHttpRequest;
                if (xmlHttp) {
                  xmlHttp.open('GET', 'getTextAsJSON.php', true);
                  xmlHttp.onreadystatechange = function () {
                    if (xmlHttp.readyState == 4) {

              //auswerten, erzeugt assoziativen Array
                      eval('data='+xmlHttp.responseText);

              // schreiben:
                      document.getElementById('titel').innerHTML=data['titel'];
                      document.getElementById('text').innerHTML=data['text'];
                      document.getElementById('quelle').innerHTML=data['quelle'];

              // wiederholen
                      wiederhole=window.setTimeout("holeDaten()", 25000);
                   }
                };
                 xmlHttp.send(null);
              }
              <script>

              Freilich bist du auch nicht gehindert, in der ursprünglichen Variante gleich serverseitig zu erzeugen, was Du auf dem Client brauchst, also etwas wie:

              <?php #getText.php
              print '<div class="title">Das ist ein toller Titel</div>';
              print '<div class="text">Das ist ein toller Text</div>';
              print '<div class="quelle">geklaut von <a href="http://bauer.ro/geschichte_vom_kuerbis.html">rumänischem Bauer</a></div>';
              ?>
              wäre recht einfach.

              Eine weitere Möglichkeit wäre str_split(). Du kannst die Strings also erst auf dem Server zu einem zusammen zu setzen und dann auf dem Client trennen. Benutze einen klug gewählten Trenner, etwas wie

              <?php
              print 'Das ist ein toller Titel<TRENNER>Das ist ein toller Text<TRENNER>geklaut von <a href="http://bauer.ro/geschichte_vom_kuerbis.html">rumänischem Bauer</a>';
              ?>

              könnte man in Javascript mit

              var ar=xmlHttp.responseText.split('<TRENNER>');

              wieder auflösen und dann mit

              document.getElementById("prevTitel")=ar[0];
              ...

              ins Dokument schreiben.

              Jörg Reinholz

            4. Tach!

              OK, hier gebe ich das PHP-Skript an, welches die Einträge aus der DB holt.
              Es handel sich dabei um einen Titel, einen Text und eine Quelle, d.h. also 3 Angaben.
              Kann ich die irgendwie trennen?

              Trennen derart, dass du sie auf der Javascript-Seite auseinanderhalten kannst? Ja. Im einfachsten Fall, indem du ein Trennzeichen einfügst (z.B. |) und an diesem splittest. Wenn dieses Zeichen auch Bestandteil der Daten sein kann und sich kein anderes findet, bietet sich der Einsatz von Containerformaten an, sprich: JSON. Dan musst du dir nur noch einen JSON-Parser bauen (zumindest für die Browser, die keinen an Bord haben) oder doch langsam die Hand nach einem Framework ausstrecken.

              dedlfix.

          3. Hallo!

            Zu Deiner Frage:

            Ich bin enttäuscht von deiner Einstellung zum Thema "self"!

            Grüße, Matze

            1. Hallo,

              Ich bin enttäuscht von deiner Einstellung zum Thema "self"!

              Ganz so hätte ich das nicht formuliert, aber tatsächlich hatte ich mir gestern überlegt einen Thread zu diesem Thema zu starten. Ich hab so den Eindruck, dass in letzter Zeit die vorgefertigten Lösungen - selbst für nichtigste Probleme - überhand nehmen. Oder täuscht das?

              Und wenn nicht: Woran liegts? Langeweile? Profilierungssucht? Überhilfbereitschaft? Die Konjunktur brummt doch... Wer hat soviel Zeit, dass er auch soviele Stunden hier zu bringt und sich in alles Mögliche reindenkt?

              Viele Grüße
              Siri

              1. Wer hat soviel Zeit, dass er auch soviele Stunden hier zu bringt und sich in alles Mögliche reindenkt?

                Jemand der ganz bewusst und eigennützig auf der Suche nach den Problemen anderer Leute ist.

                Jörg Reinholz

                1. Wer hat soviel Zeit, dass er auch soviele Stunden hier zu bringt und sich in alles Mögliche reindenkt?

                  Jemand der ganz bewusst und eigennützig auf der Suche nach den Problemen anderer Leute ist.

                  Also doch Langeweile? ;-)

                  1. Also doch Langeweile? ;-)

                    Nein. Ich werde oft gebucht nachdem die Teilnehmer erst mal 'learning by doing' versuchten. Hier erhalte ich ganz nette Hinweise darauf, was mich in den Seminaren dann so an Fragen erwartet.

                    Es ist für mich gut, wenn ich derlei Lösungen (sind ja oft 10-Zeiler) schon mal gestrickt und so als Fallbeispiel parat habe. Nenn es nicht Langeweile sondern "stetige Seminarvorbereitung" oder meinetwegen Weiterbildung.

                    Weniger triviales veröffentliche ich gern auch mal. (Beispiel)

                    Jörg Reinholz

      5. Moin!

        jQuery-Framework-Geschwuchtel

        ymmd

        Sehr schoen gesagt. :)

        --
        Signaturen sind blöd!
        1. Hallo!

          jQuery-Framework-Geschwuchtel

          ymmd

          Sehr schoen gesagt. :)

          Mitnichten! Das Framework hat, ohne Zweifel, seine Daseinsberechtigung. Es als "Geschwuchtel" zu bezeichnen zeugt widerum, ohne Zweifel, von wenig Objektivität und Ahnung.

          Grüße, Matze

          1. Ja, moinsen!

            jQuery-Framework-Geschwuchtel

            ymmd

            Sehr schoen gesagt. :)

            Mitnichten! Das Framework hat, ohne Zweifel, seine Daseinsberechtigung. Es als "Geschwuchtel" zu bezeichnen zeugt widerum, ohne Zweifel, von wenig Objektivität und Ahnung.

            Sicher hat jquery sowas wie eine Daseinsberechtigung. Das haben Massentierhaltung und Dreamweaver auch.

            Aber einfach: "Nimm jquery, das ist einfacher. Du musst gar nicht wissen wie das geht." (Also quasi lern nicht Javascript, lern jquery) zu sagen ist was? Richtig.

            jQuery ist nett wenn man es auch ohne kann. Aber in meinen Augen, und ich bilde mir zumindest ein, dass das hier auch immer öfter auftaucht, können die Leute nur noch jQuery und haben kein Verständnis mehr für das eigentliche JavaScript oder eben Programmierung im Allgemeinen.

            Also: jQuery-Framework-Geschwuchtel!

            --
            Signaturen sind blöd!
            1. Hi,

              jQuery ist nett wenn man es auch ohne kann. Aber in meinen Augen, und ich bilde mir zumindest ein, dass das hier auch immer öfter auftaucht, können die Leute nur noch jQuery und haben kein Verständnis mehr für das eigentliche JavaScript oder eben Programmierung im Allgemeinen.

              Das ist sicherlich wahr, aber ein Problem von den Leuten und nicht von jQuery.

              Also: jQuery-Framework-Geschwuchtel!

              Das Problem ist eigentlich, dass mit jQuery meistens Code produziert wird, der sehr nah am DOM oder sogar im DOM operiert. Und das ist eigentlich sehr unschön. Vergleiche mal jQuery mit einem Framework wie angularJS, dann siehst du, wie gut man DOM und JavaScript-Applikationslogik trennen kann.

              Bis die Tage,
              Matti

            2. Om nah hoo pez nyeetz, Steel!

              Aber einfach: "Nimm jquery, das ist einfacher. Du musst gar nicht wissen wie das geht." (Also quasi lern nicht Javascript, lern jquery) zu sagen ist was? Richtig.

              jQuery ist nett wenn man es auch ohne kann. Aber in meinen Augen, und ich bilde mir zumindest ein, dass das hier auch immer öfter auftaucht, können die Leute nur noch jQuery und haben kein Verständnis mehr für das eigentliche JavaScript oder eben Programmierung im Allgemeinen.

              Ich behaupte mal, dass das so nicht richtig ist. Wenn man tatsächlich etwas programmieren muss, bietet JQuery keine Vorteile, denn die Programmierlogik muss man schon selbst entwickeln.

              Dass man mit JQuery hingegen Elemente im DOM wesentlich (!!11elf) einfacher selektieren und mit ihnen umherspielen kann, ist ein großer Vorteil.

              $('body') vs. document.getElementsByName0;

              Es ist wie mit Kopfrechnen vs. Taschenrechner. Man sollte beides gut können. Aber vor allem das Hilfsmittel Taschenrechner richtig bedienen.

              Matthias

              --
              1/z ist kein Blatt Papier.

              1. Hi!

                Es ist wie mit Kopfrechnen vs. Taschenrechner. Man sollte beides gut können. Aber vor allem das Hilfsmittel Taschenrechner richtig bedienen.

                Da ist aber das Problem. Was der Taschenrechner ausspuckt ist korrekt. Unser Mathelehrer damals hat sich darueber oft aufgeregt, dass viele Schueler unreflektiert niederschreiben, was der "Hirnzellenzerstoerer" ausspuckt. Da wurde nicht ueberlegt. Wenn Die Aufgabe 356/12 war und der sagte 4380 dann war das auch 4380. Fertig. Dass man mit minimalem Denkaufwand erkennen koennte dass hier ein Fehler vorliegt spielt dabei keine Rolle. Wird heute in den Schulen wohl kaum anders sein.

                Ich habe nichts gegen Taschenrechner. Ich liebe meinen Taschenrechner. Ich, mit meiner kleinen Rechenschwaeche bei kleinen Zahlen und Zehnerwechsel, benutze meinen Taschenrechner fuer jeden Kram. (wie? 7+5 ist nicht 13?!) Aber ich merke fuer gewoehnlich wenn das was nicht stimmt. Und wenns sein muss, dividiere ich mir die Auktionshauspreise im MMO auch aufm Blatt Papier zusammen und addiere mir meine XP und GP im Pen & Paper im Kopf auseinander. Des macht aber keinen Spass.

                --
                Signaturen sind blöd!
                1. Om nah hoo pez nyeetz, Steel!

                  Es ist wie mit Kopfrechnen vs. Taschenrechner. Man sollte beides gut können. Aber vor allem das Hilfsmittel Taschenrechner richtig bedienen.

                  Da ist aber das Problem. Was der Taschenrechner ausspuckt ist korrekt. Unser Mathelehrer damals hat sich darueber oft aufgeregt, dass viele Schueler unreflektiert niederschreiben, was der "Hirnzellenzerstoerer" ausspuckt. Da wurde nicht ueberlegt. Wenn Die Aufgabe 356/12 war und der sagte 4380 dann war das auch 4380. Fertig. Dass man mit minimalem Denkaufwand erkennen koennte dass hier ein Fehler vorliegt spielt dabei keine Rolle. Wird heute in den Schulen wohl kaum anders sein.

                  Du sprichst mir aus der Seele.

                  Matthias

                  --
                  1/z ist kein Blatt Papier.

              2. [latex]Mae  govannen![/latex]

                $('body') vs. document.getElementsByName0;

                Ok, hier ist jCrappy im Vorteil, da die andere Variante direkt zwei Fehler enthält. Respekt ;)

                document.body genügt.

                So, umd nun zähle mal alles hinzu, was jCrappy im Hintergrund tun muß, um diese Referenz zu ermitteln. Die Funktion $() muß den Parameter auswerten und jede Menge Voodo ausführen, nur um dann ihrerseits doch auf document.body zuzugreifen (Ich glaube nicht, daß jCrappy noch so alte Browser unterstützt, die document.body nicht kennen und auf gEBTN angewiesen sind).

                Ansonsten: Siehe Sig ;)

                Stur lächeln und winken, Männer!
                Kai

                --
                var jQuery = $(hit);
                I am Pentium of Borg. Division is futile. You will be approximated.
                SelfHTML-Forum-Stylesheet
                1. Om nah hoo pez nyeetz, Kai345!

                  So, umd nun zähle mal alles hinzu, was jCrappy im Hintergrund tun muß, um diese Referenz zu ermitteln. Die Funktion $() muß den Parameter auswerten und jede Menge Voodo ausführen, nur um dann ihrerseits doch auf document.body zuzugreifen

                  Korrekt. Ändert jedoch nichts daran, das JQuery ein Werkzeug ist, das einem das Selektieren von Elementen deutlich vereinfacht.

                  So, und nun zähle mal alles hinzu, was ein Taschenrechner tun muss, ...

                  Matthias

                  --
                  1/z ist kein Blatt Papier.

                  1. [latex]Mae  govannen![/latex]

                    So, umd nun zähle mal alles hinzu, was jCrappy im Hintergrund tun muß, um diese Referenz zu ermitteln. Die Funktion $() muß den Parameter auswerten und jede Menge Voodo ausführen, nur um dann ihrerseits doch auf document.body zuzugreifen

                    Korrekt. Ändert jedoch nichts daran, das JQuery ein Werkzeug ist, das einem das Selektieren von Elementen deutlich vereinfacht.

                    Sicher. Aber eines, das man nicht unbedingt benötigt, wenn es um Element-Selektierung geht:

                    document.querySelector() und document.querySelectorAll() existieren nun schon eine ganze Weile (Chrome 1, Firefox 3.5, Opera 10, Safari 3.2, IE 8) und sollten für ~ 99% der Fälle ausreichend sein (größte Einschränkung ist IE8, der nur CSS2-Selektoren versteht). Notfalls ist Sizzle auch separat einbindbar, falls ein ganz spezieller Anwendungs-Fall auftreten sollte (Das was ich bisher auf diversen Sites an Code durchstöbert habe, war problemlos auch "ohen" lösbar, da es fast immer einfache (IDs, Klassen, Verschachtelungen) Selektoren waren).

                    Wie heißt es so schön:
                    when all you have is a hammer { jQuery }, everything looks like a nail { $() }.

                    Stur lächeln und winken, Männer!
                    Kai

                    --
                    var jQuery = $(hit);
                    I am Pentium of Borg. Division is futile. You will be approximated.
                    SelfHTML-Forum-Stylesheet
                    1. Hallo,

                      ein Werkzeug […], das einem das Selektieren von Elementen deutlich vereinfacht.
                      Sicher. Aber eines, das man nicht unbedingt benötigt, wenn es um Element-Selektierung geht

                      jQuery ist eine kompakte funktionale und objekt-orientierte Schnittstelle zum Arbeiten mit Elementlisten, zum Traversieren des DOM, zur DOM-Manipulation, für Ajax, JavaScript-basierte CSS-Animationen uvm. Die W3C-DOM-APIs sind umständlich, inkonsistent, enthalten Designfehler, sind immer noch unterschiedlich implementiert. XMLHttpRequest ist eine schreckliche API, für deklarative CSS-Animationen fehlen vernünftige APIs, Event-Handling ist ein totales Chaos.

                      jQuery ist eine kompaktere, leistungsfähigere und relativ einheitliche API, welche eine Reihe von sinnvollen Patterns beinhaltet und forciert, und ist daher mehr als die Summe seiner Teile. Neben der Nivellierung von Browserunterschieden ist der Erfolg von jQuery und die Auswirkung auf andere Bibliotheken darauf zurückzuführen. jQuery hat sich als Metasprache etabliert, weil die zugrundeliegende Sprache wenig geeignet ist, um Anwendungslogik auszudrücken (und selbst dafür ist jQuery noch zu wenig abstrakt, siehe Mattis Posting).

                      Das Betrachten einzelner Funktionen hilft einem beim Verständnis von jQuery nicht weiter. Ein Vergleich mit Low-Level XHR, QSA, DOM-Manipulation usw. ist unangebracht. Zum einen existieren auch in aktuellen Browsern noch Fallstricke, wie sich im Code jeder DOM- und Ajax-Bibliothek nachlesen lässt. Zum anderen ist es selbstverständlich, dass sich eingeschränkte, scharf umgrenzte Use-Cases mit weniger Code Low-Level schneller und kürzer umsetzen. »Das lässt sich auch ohne jQuery machen« ist kein Argument gegen vernünftige Abstraktionen und für die Benutzung von problematischen Low-Level-APIs. Es ist ein Argument dafür, zu verstehen, was überhaupt vor sich geht beim Aufruf von Fremdcode.

                      Es ist beileibe nicht einfach, gut strukturierten und performanten jQuery-Code zu schreiben. Dazu bedarf es ein detailliertes Wissen von jQuery *und* den zugrundeliegenden APIs (document.body war schon ein schönes Beispiel). Aber es ist unverhältnismäßig schwerer, robusten, abstrakten und wartbaren Code gänzlich ohne allgemein akzeptierte DOM- und Ajax-Abstraktionen zu schreiben.

                      Grüße,
                      Mathias

            3. Hallo!

              Also: jQuery-Framework-Geschwuchtel!

              Ich verstehe die Gründe gegen jQuery sehr wohl, allerdings ist ein Vorteil von jQuery, dass ich mich nicht mehr um Browser-Kompatibilität kümmern muss und den möchte ich nicht mehr missen.

              Das Ajax-Beispiel ist z.B. nicht überall lauffähig. Muss es sein, dass der Programmierer für den Browser programmiert und nicht für JavaScript? Nein! Diese ewigen, teilweise umständlichen, Unternehmen mit denen man in bestimmten Situationen Browser-spezifisch programmieren muss, nerven einfach nur. Das Framework nimmt mir dieses "Geschwuchtel" ab.

              Zumal man auch bedenken muss, dass es in der Regel nicht mit einem einfach Ajax-Request getan ist. Es braucht also noch eine Folgelogik. Und dabei muss man zwangläufig pures JavaScript benutzen. Syntax, Funktionen, Variablen etc. dadurch fällt auch das Argument "man lernt kein JavaScript sondern jQuery" weg. jQuery vereinfacht nur bestimmte Abläufe.
              Ich sehe, vor allem durch den modularen Aufbau, nur Vorteile in einem ordentlichen Framework. Sei es jQuery, mooTools oder was auch immer.

              Niemand zwingt einen beim Einsatz von jQuery übrigens dazu auf document.body zu verzichten.

              Ich finde die Diskussion bezüglich Frameworls allerdings interessant. Was haltet ihr von QT versus purem C++?

              Grüße, Matze

              PS: es war schon spät an dem Abend der posts und ich hatte nicht den besten Abend. Im nachhinein kommen mir die posts selbst sehr Arrogant und Agressiv vor. Ich hoffe, dass sich niemand angegriffen gefühlt hat. Falls dem so ist, entschuldige ich mich dafür!

              1. Moin!

                PS: es war schon spät an dem Abend der posts und ich hatte nicht den besten Abend. Im nachhinein kommen mir die posts selbst sehr Arrogant und Agressiv vor. Ich hoffe, dass sich niemand angegriffen gefühlt hat. Falls dem so ist, entschuldige ich mich dafür!

                Wus? Wer ist gestorben? Also ich mach mich jetzt auf zur Arbeit. Vorher noch ein paar Brötchen kaufen. Um spätestens 20:00 möcht ich zuhause sein um die neue Folge Big Bang Theory zu schauen. Meinst Du das? ;)

                --
                Signaturen sind blöd!