AJAX - Javascript geht in response-Datei nicht

Was mache ich falsch wenn in dem File das ich mir per AJAX hole Javascript nicht ausgeführt wird. Scriptfehler werden keine angezeigt jedoch der Code auch nicht ausgeführt...?

Die Daten werden per Ajax folgendermaßen geholt:

var xmlhttp=false;
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
xmlhttp = new XMLHttpRequest();
}

function getMyHTML(serverPage, objID) {
var obj = document.getElementById(objID);
xmlhttp.open("GET", serverPage);
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
obj.innerHTML = xmlhttp.responseText;
}
}
xmlhttp.send(null);
}

Treffen sich zwei Cowboys im Saloon. Welcher Schmied hat das Pferd des Wirts beschlagen?

Sorry aber ohne ein paar Daten können wir dir schlecht helfen. Wie sieht dein AJAX-Script aus? Wie rufst du es auf? usw..


Und du brauchst dir keine Sorgen machen, dass wir dir dein AJAX-Script klauen. Ich und viele andere haben bereits unsere eigenen Scripts.. bei Interesse kann ich dir meine AJAX-Klasse/Script auch gerne einmal zuschicken.

Dachte eben das das so allgemein bekannst ist, dass nicht nur ich das Problem damit habe, dass anschliessend in den neuen Datei kein Javascript ausgeführt wird. Code für Ajax oben reineditiert.

Auf den ersten Blick siehts noch recht ordentlich aus und ich wollte eben mal ne Testseite draus machen. Aber vorweg: Du weisst, dass der Abschnitt hier auskommentiert ist und somit kein XMLHttpRequest aufgebaut werden kann.

/*@if (@_jscript_version >= 5)

try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/

So und bei mir funktioniert es soweit dann auch:

index.htm (die Grundseite)

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


Test

/* var xmlhttp=false;
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
xmlhttp = new XMLHttpRequest();
}

function getMyHTML(serverPage, objID) {
var obj = document.getElementById(objID);
xmlhttp.open("GET", serverPage);
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
obj.innerHTML = xmlhttp.responseText;
}
}
xmlhttp.send(null);
}
/* ]]> */




Ein Test




test.php (Die Seite die das Update ausgibt)

echo "Ein neuer Inhalt";

?>

Was du aber an deinem Script vergessen hast, ist der Standard-XMLHttpRequest(). Du verwendest nur die ActiveX-Klassen von MS, was entsprechend nur bei Windoof funktioniert. Hier mal die Variante die ich normalerweise verwende..

  if (window.XMLHttpRequest) {

    httpObject = new XMLHttpRequest();

  } else if (window.ActiveXObject) {

    try {

      httpObject = new ActiveXObject("Microsoft.XMLHTTP");

    } catch(e) {

      httpObject = new ActiveXObject("Msxml2.XMLHTTP");

    }

  }

Bis auf den auskommentierten Bereich aus deinem Script ist es soweit in Ordnung.. Hoffe das dir die Beispiele so ein wenig helfen.

Original von Mudder


test.php (Die Seite die das Update ausgibt)

echo "Ein neuer Inhalt";
?>

Danke für die Hilfe. Gib mal bitte deinem Testcript test.php noch irgendwelche Javascriptcode mit z.B. einen Mouseovereffekt. Mich würde interessieren ob der dann bei dir ausgeführt wird oder auch bei dir nichts bewirkt, da hänge ich gerade?

So Script eben erweitert und zwei Buttons mit mouseover-Efffekt eingebaut.

index.htm

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


Test

/* var xmlhttp=false;
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
xmlhttp = new XMLHttpRequest();
}

function getMyHTML(serverPage, objID) {
var obj = document.getElementById(objID);
xmlhttp.open("GET", serverPage);
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
obj.innerHTML = xmlhttp.responseText;
}
}
xmlhttp.send(null);
}
/* ]]> */




Ein Test







test.php

if ($_GET['page'] == "1") {

  echo "Dies ist Seite 1";

} elseif ($_GET['page'] == "2") {

  echo "Dies ist Seite 2";

} else {

  echo "Das ist eine andere Seite mit einem anderen Inhalt!";

}

?>

Erklärung:
In der index.htm wurden vor allem die beiden Buttons eingebaut.
In der test.php habe ich ne Unterteilung mit der $_GET['page'] eingebaut um 3 verschiedene Inhalte auszugeben.

Ok und wenn bei mir in der test.php Javascript enthalten ist


alert("test");


Wird dieser nicht ausgeführt.

Die weiteren Änderungen
index.htm (der -Bereich)

Ein Seiteninhalt 

Ein Test


test.php

if ($_GET['page'] == "1") {

echo "Dies ist Seite 1";
} elseif ($_GET['page'] == "2") {
echo "Dies ist Seite 2";
} else {
echo "Das ist eine andere Seite mit einem anderen Inhalt!



";
}
?>

Original von Duke_
Ok und wenn bei mir in der test.php Javascript enthalten ist


alert("test");


Wird dieser nicht ausgeführt.

Warum willst du denn Javascriptcode eigentlich per Ajax übertragen lassen? Kannste auch gleich mitschicken

Original von KoMtuR

Warum willst du denn Javascriptcode eigentlich per Ajax übertragen lassen? Kannste auch gleich mitschicken

Ausgangspunkt ist die Bewegung einer Einheit auf einer Karte von A nach B. Per Ajax holen ich mir die Aktualisierung der 2d Karte, Felddaten + Einheitendaten. Die Bewegung der Einheit von Ausgangsfeld zum Zielfeld geschieht per Javascript, was jetzt nicht mehr geht. Die Eventhandler gehen aber Code zwischen bla nicht.

Ähm..
wenn du jetzt mein Beispiel genommen hast dann musst du beachten, dass ich XHTML verwendet habe und du und Bereiche mit

/* ...

/* ]]> */

abgrenzen musst.

Original von Mudder
Auf den ersten Blick siehts noch recht ordentlich aus und ich wollte eben mal ne Testseite draus machen. Aber vorweg: Du weisst, dass der Abschnitt hier auskommentiert ist und somit kein XMLHttpRequest aufgebaut werden kann.

/*@if (@_jscript_version >= 5)

try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/

Nicht ganz richtig, das nennt sich Conditional compilation.

@Duke
Versuchs mal mit eval

Klappt das jetzt mit dem JS-Code per Ajax?

Wir hatten unsere Werbebanner zuerst mittels Ajax neu geladen (d.h. meist ein neues JS geladen) und das hatte nicht funktioniert, weil das Script nicht ausgefuehrt wurde.

Wir haben den Ansatz dann erstmal nicht weiterverfolgt und die Werbebanner per iframe-reload neu geladen.

Soviel ich weiss nicht...
*3 Minuten später*
Nope geht nicht! Habs eben in dem Testscript mal mit eingebaut und JS-Scripts werden nicht mit integriert.

Für sowas hab ich bei meiner AJAX-Klasse Unterfunktionen mit eingebaut welche nicht nur Element-Updates bearbeiten können sondern z.B. alert()-Meldungen ausgeben, Meldungen ausgeben (welche direkt ins Design integriert sind, usw..

Ich verstehs immernoch welchen Nutzen dies bezweckt, wenn ich statt der sofortigen Einbindung des JS-Codes erst mittels Ajax mir diesen Mist hole? Code doch nen ordentliches Frontend, wo man nur angibt: Einheit geht von a nach b. nun mach ma.

Komm nun aber nicht mit: Damit nicht jeder meinen JS-Code sehen kann. Sonst muss ich anfangen mit lachen

Der Funktionsaufruf innerhalb von mit der Übergabe der neue Wegkoordinaten kommt erst mit den aktualisierten Daten.

Ja nur dann solltest du dir evtl. eine Art Engine bauen.
Ich habe z.B. schon ein kleines CMS-System draus gemacht wo ich mittels XML-Struktur verschiedene Update-Anweisungen an das JS-Script schicken kann.

Da sind die normalen Element-Updates, aber auch z.B. das -Felder neue Werte erhalten, das sich ne Nachricht (als so ne Art alert-Message) über den Bildschirm legt oder auch ganze Streaminganweisungen wo das JS-Script sich nach und nach ganze Listen von Elementen runterläd. (das ist in Admin-Systemen ganz praktisch)

Für deine Gameengine sollte neben den Element-Updates eben solche Bewegungsanweisungen mit integriert werden welche nicht den Inhalt eines Elements ändern sondern die Style-Anweisungen für top und left..

123
393
96


Das musst du jetzt nicht unbedingt in XML-Form machen, sondern auch ganz simpel im CVS-Format (mit ; getrennt) gestallten nur das du eben eine andere Funktion für den "Marschbefehl" anweist das Update zu holen. Die Funktion ändert dann nicht den innerHTML-Bereich sondern zerlegt den String und setzt das Element an die neue Ecke..

Hmmm... bin ich dov? Wenn ihr die Daten via XMLHTTP erhält. Und ihr wollt das ganze (javascript) ausführen... Wo ist dann das Problem?

Es gibt nur probleme, wenn HTML und JS in einer Antwort gemischt ist; ansonsten wenn da nur JS kommt -> dieses Laden, Ausführung beginnen, sense.
Ansonsten (wenn es gemischt ist) muss man halt rasch nach dem JS parsen; dieses ausschneiden und nach dem Aufbau des DOMs wieder in diesen Laden.

Gruss

Nein du bist nicht zu dov.. du bist nur zu blöd "doof" richtig zu schreiben

Deine Variante benötigt aber auch eine individuelle Behandung.. klar wenn man nur JS-Code hinschickt und den dann direkt im Verarbeitungsscript ausführt könnte(weiss ich so auch nicht) es funktionieren. Aber wie gesagt diese Variante benötigt auch eine eigene Behandlung da mit der selben Funktion ja eben auch Textelemente und Co geändert werden können.

Aus dem Grunde verwende ich ja auch wie gesagt ne Art CMS welche mittels XML-Struktur automatisch die richtigen Anweisungen ausführt. Nur bei der Variante von Duke_ da bringt deine Variante eben recht wenig weil er so oder so neue Bearbeitungsfunktionen einbauen muss - ich aber einfach mal behaupten möchte, dass ne Art XML-Struktur deutlich besser für ein BG geeignet ist als einfaches JS-geparse.

Du hast ja recht, ich würde das ganze auch nicht so machen wie Duke aber dennoch kanns immer mal praktisch sein (für ausnahmesituationen siehe unten).

Also: WENN du weist, dass es JS ist, kannst du dieses sehr schnell zur Ausführung bringen. Das ist kein Problem... -> probiers mal aus?
Wenn du es nicht weist hast du folgende Situation:
a) das JS ist ein Event (onClick; onLoad; ...) Diese Sachen lassen sich ebenfalls mit praktisch 0 Aufwand laden...
b) Es ist einfach so "anonymer JS Code". Diesen must DU erkennen können -> denn woher soll der arme Browser wissen was dass er diese Code auch ausführen soll? Einblenden des Codes im DOM Tree ist keine Sonderbehandlung -> die Ausführung schon.

Will heissen? Du hast ca. 5 bis 10 Zeilen zum Laden von Text, HTML, JavaScripts, ...
Danach nochmals ca. 20 bis 30 Zeilen, welche Anonymes JS ausführen können.

Die Frage ist immer: Überträgst du Daten (XML), oder überträgst du Darstellungsdaten (HTML). Wenn du HTML überträgst, wie gesagt hast kein Problem (ausser mit Anonymem Code was man eh ned macht).
Wenn du selbst Nutzdaten überträgst -> dann must ja auch du das Format kennen sprich du must das JS erkennen und korrekt behandeln.

Lange rede kurzer Sinn: Entweder du weist, was der Server dir sendet -dann kannst du ohne Probleme darauf eingehen - oder du weist es ned.


Und wieso JS noch sehr interessant sein kann? Ganz einfach. Stell dir mal folgendes vor: Du entwickelst ein AJAX PHP. Was ist die grösste Herausforderung daran (server-Seite). RICHTIG: Du siehst kein Frontend!
Noch dof, gel? Vorallem dann wenn das PHP ne Warning oder n Error wirft?


Genau in DEM Fall macht es sinn, wenn man ein atomares Konstrukt im sinne eines alert(die PHP Warning); senden kann.
Der Client dieses dann einfach ausführt -> man sieht was los ist.
überträgst du gar kein JS hast du folgendes Problem: Die Warning kann theoretisch überall kommen... sprich innerhalb eines beliebigen Elementes; innerhalb eines beliebigen Textes. Somit musst du auf sämtlichen Ebenen des DOM Baums der übertragenen Daten nach einem Sonder-Tag für Errors suchen. Sehr mühsam.

Glaub mir: Spätestens dann wenn du in einer Entwicklung n Failsafe Test machst, wirst du die alert Errors lieben.

das ist DER grund wieso ich immer nebst Datenübertragung auch JS übertragung ermöglichen werde. Hat aber auch einen Nachteil:
Das Protokoll erlaubt dann die übertragung beliebigen JS. Sprich man verliert den sinn dahinter, dass der Server Client unabhängig ist. Zudem kann ein gehackter Server dazu dienen, Daten aus dem Client (Browser) auszulesen. Die Lösung dieses Problemes verkauf ich dir nur gegen $$$


Gruss

Um nun PHP-Fehlermeldungen auszugeben da würde ich ganz einfach mein $ajax->add_msg($topic, $message); verwenden.. schön verpackt in einer dem User verständlichen Fehlermeldung ("Wenn da steht 'Adresse' dann hat da nicht 'asdasd' zu stehen!" oder "Kinder unter 18 Jahren haben auf dieser Seite nichts zu suchen..")

Einfache Syntax-Errors würde ich sicher nicht über das fertige Interface prüfen sondern die jeweiligen PHP-Funktionen direkt ansprechen..


Ich bleib jedenfalls bei meiner XML-CMS Variante und wenn ich da JS-Ausführen will dann gibts für mich immernoch $ajax->eval_script($script);

Moment, ich red von PHP Runtime Errors Division durch 0; Script Timeout, ... Sollte es NIE geben, leider lassen sich nicht ganz alle ausschliessen.
Die kannst du nicht so schnell einfach so rasch in ein ajax_... packen
Die kannst gerade mal formatieren.
Und die konnen auch mitten im output .... PHP ERROR... kommen

DIESE Fehler sind recht mühsam abzufangen und ich behaupte mal, dass du die nicht immer sinnig ausgeben kannst...

Gruss

Dann mach ich das einfach so, dass ich keine Fehler produziere und dann gibts ja noch das niedliche kleine @

Naja mit den Exceptions in PHP5 wird es aber möglich sinnige Ausgabe zu produzieren. Nur muss man sich erstmal durchringen wirklich alles in try-catch zu bauen, was fehleranfällig ist.

Das mit den Try-Catches ist gut und recht, das stimmt.
Die Frage ist nur, ob man alle möglcihen Fehlerquellen erwischt.

Wenn man alle Fehler so erwischt ist gut, anderenfalls hat man n kleines Problem bei unsichtbaren Frames. Mal zum Background: Habe sowas mal 5 Stunden lang gesucht -> jeweils ein nicht reproduzierbarer JavaScript aufhänger. Bis ich per zufall mal sniffen ging und dort die Error-Meldung gesehen hab

Im Betrieb kann sowas nicht auftreten, da eh alle Warnings ausgeschaltet sind... aber beim Debuging ist sowas lästig.

Gruss

Naja ich denke solange man auf sich selbst baut und weiß was man macht brauch man nur die Daten, die von aussen kommen, catchen. Klar wird man immer mal eine Fehlermeldung nicht erwischen, aber dafür kann man das ja dann nachbessern

Gibt ja kein perfekten Code