nicht angemeldet Matti Mäkitalo
Der Martin
Matti Mäkitalo
dedlfix
Matti Mäkitalo
Matthias Apsel
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
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
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();
}
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
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
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
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
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:
Ganz lieben Dank
Bitte.
und schöne Träume :-)
"Eine Welt ohne Miesepeter ... Hach, das wär was!"
wiederhole=window.setTimeout(" holeDaten()", 25000);
wiederhole=window.setTimeout("holeDaten()", 25000);
Sorry. Ein Leerzeichen zu viel.
Jörg Reinholz, Genauheim
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
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
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
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
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!
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');
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
tabelleWHERE id != '".$_GET['idcheck']."' ORDER BY prioritaet*RAND() Limit 0,1Geht 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
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'
setcookie('lastSnipplet',row['id'])
Damit steht beim nächsten Aufruf in $_COOKIE['lastSnipplet'] die ID des letzten Datensatzes, der dem Client gesendet wurde.
<?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>
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
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.
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
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
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?
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
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.
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
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.
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.
Hallo!
Zu Deiner Frage:
Ich bin enttäuscht von deiner Einstellung zum Thema "self"!
Grüße, Matze
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
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.
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? ;-)
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
Moin!
jQuery-Framework-Geschwuchtel
ymmd
Sehr schoen gesagt. :)
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
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!
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
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
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.
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
[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);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.bodyzuzugreifen
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
[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.bodyzuzugreifenKorrekt. Ä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);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
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!
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? ;)