Ajax nachladen
0 0 
Robert B.
0 0 
Gunnar Bittersmann
0 Robert B.
Ajax nachladen
JürgenBHallo Forum,
da ich ein wenig mit Jquery UI hadere, würde ich anstattdessen gerne mal etwas anderes probieren. Ich habe auch schon etwas gefunden, was mir gefällt. Leider schaffe ich es nicht, über Jquery/Ajax hier in den Modaldialog ein externes Formular einzuladen. Woebi...ich merke gerade, dass ich dazu gar nicht Jquery-Ajax, sondern Jquery-load bräuchte. Die Frage bleibt trotzdem dieselbe, ich weiß nicht genau, wo und wie einzubinden…
Kann mir jemand helfen?
Pit
-
Hmm,
ein Formular nachladen, da brauchst Du doch kein Ajax. Das hängste einfach ans <body>-element, [positionierst es in die Mitte][ und machst es sichtbar].
Nur die Daten holste dann mit ajax. MfG
-
Hi pl,
ein Formular nachladen, da brauchst Du doch kein Ajax. Das hängste einfach ans <body>-element, [positionierst es in die Mitte][ und machst es sichtbar].
Nur die Daten holste dann mit ajax. MfG
Nuja, klar. Das meinte ich auch. Aber selbst dazu würde doch die load-function völlig ausrweichen, solange ich keine rücklaufenden Daten für den Client benötige. Ich denk, ich versuche mal, die load-function direkt an doe click-function anzuhängen, da wird sie wohl hingehören… Pit
-
Aber selbst dazu würde doch die load-function völlig ausrweichen, solange ich keine rücklaufenden Daten für den Client benötige. Ich denk, ich versuche mal, die load-function direkt an doe click-function anzuhängen, da wird sie wohl hingehören…
Klasse, ich habs geschafft! Leider zeigt die Konsole noch einen Fehler an:
XML-Verarbeitungsfehler: Nicht übereinstimmendes Tag. Erwartet: </link>Pit
-
Hallo,
lade ich die Seite mit:
$('#' + modal + ' .sm_area_bottom').load( "./test.html");
nach, wird sie angezeigt. Aber mit:
$('#' + modal + ' .sm_area_bottom').load( "./test.php");
nicht, obwohl die php-seite existiert und der Pfad genau derselbe ist, wie die test.html.
Inhalt der php-datei:
<?php echo("Dies ist ein Test"); ?>Kann sich hierauf einer einen reim machen?
Edit: Konsole meint: XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden
pit
-
Tach!
Kann sich hierauf einer einen reim machen?
Das kann ich dir ganz genau sagen: Das liegt an der Ursache.
Die solltest du ermitteln mit allen zur Verfügung stehenden Werkzeugen. Zunächst mal die Entwicklertools im Browser. Schau dir an, was da über die Leitung geht. Statuscodes und Inhalte sind nicht uninteressant. Weiterhin Errorlogs auf dem Webserver.
dedlfix.
-
Tach!
Kann sich hierauf einer einen reim machen?
Das kann ich dir ganz genau sagen: Das liegt an der Ursache.
Die solltest du ermitteln mit allen zur Verfügung stehenden Werkzeugen. Zunächst mal die Entwicklertools im Browser. Schau dir an, was da über die Leitung geht. Statuscodes und Inhalte sind nicht uninteressant. Weiterhin Errorlogs auf dem Webserver.
dedlfix.
Danke.
-
-
Kann sich hierauf einer einen reim machen?
Edit: Konsole meint: XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden
Wenn jemand noch Hinweise hat, würde ich mich darüber sehr freuen.
Pit
-
hi,
Edit: Konsole meint: XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden
Offensichtlich wird in der Response XML/HTML erwartet aber deine Response bringt nur ein bischn Text. In der Console::Netzwerkannalüse solltest Du das nachvollziehen können. Die Schlussfolgerung daß PHP nicht geht ist also falsch.
Mfg 😉
-
Edit: Konsole meint: XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden
Offensichtlich wird in der Response XML/HTML erwartet aber deine Response bringt nur ein bischn Text. In der Console::Netzwerkannalüse solltest Du das nachvollziehen können. Die Schlussfolgerung daß PHP nicht geht ist also falsch.
Hi pl,
die Konsolenmeldung von Firefox ist einfach nicht gut. Ich habs nun im Chrome aufgerufen und erhalte eine deutlich aussagekräftigere Fehlermeldung, nämlich, dass emine test.php nicht geladen werden kann, bzw. wenn sie geladen wird, nicht interpretiert wird. Da habe ich "Schussel" doch glatt vergessen, den Seitenaufruf überhaupt über den Apachen laufen zu lassen schäm und dann ists klar, dass die php-Datei uninterpretiert nur ein bischen Text liefert. Nun übern localhost, Apachen und php-Interpreter läuft es natürlich. Danke für die Hilfe, Pit
-
Tach!
die Konsolenmeldung von Firefox ist einfach nicht gut. Ich habs nun im Chrome aufgerufen und erhalte eine deutlich aussagekräftigere Fehlermeldung,
Ja, das hab ich auch gelegentlich bemerkt, dass der Chrome mitunter die aussagekräftigere Meldung liefert.
nämlich, dass emine test.php nicht geladen werden kann, bzw. wenn sie geladen wird, nicht interpretiert wird. Da habe ich "Schussel" doch glatt vergessen, den Seitenaufruf überhaupt über den Apachen laufen zu lassen schäm und dann ists klar, dass die php-Datei uninterpretiert nur ein bischen Text liefert.
Aber dazu braucht man die Fehlermeldung nicht unbedingt, das kann man auch erkennen, wenn man im Netzwerk-Tab sich den Request und das Ergebnis anschaut. Man kann sich da Headerzeilen und Inhalt wunderbar anschauen, und hätte so merken können, dass da der Server was falsches liefert. Es hat schon seinen Grund, nach der Ursache zu suchen und dazu die den Entwicklern gebotenen Möglichkeiten zu nutzen. Erfahrung heißt nicht, aus einem "geht nicht" zu wissen wie man es repariert, sondern zu wissen wo man nachschauen muss, um Meldungen zu bekommen und um sich von der korrekten Arbeitsweise der einzelnen Komponenten des Gesamtsystems zu überzeugen.
Die Sache mit dem PHP hätte man in dem Fall auch finden können, indem man die URL direkt aufruft. Zudem sollte die erste Maßnahme nach dem Konfigurieren von PHP sein, mit einer Testdate mit Inhalt
<?php phpinfo();dessen Funktionieren zu bestätigen.dedlfix.
-
Hallo,
Aber dazu braucht man die Fehlermeldung nicht unbedingt, das kann man auch erkennen, wenn man im Netzwerk-Tab sich den Request und das Ergebnis anschaut. Man kann sich da Headerzeilen und Inhalt wunderbar anschauen, und hätte so merken können, dass da der Server was falsches liefert.
Nicht ganz richtig. Man hätte nur merken können, dass der Server gar nicht mitläuft. Aber davon ab, bisher kannte ich den Netzwerk-Tab gar nicht.
Es hat schon seinen Grund, nach der Ursache zu suchen und dazu die den Entwicklern gebotenen Möglichkeiten zu nutzen. Erfahrung heißt nicht, aus einem "geht nicht" zu wissen wie man es repariert, sondern zu wissen wo man nachschauen muss, um Meldungen zu bekommen und um sich von der korrekten Arbeitsweise der einzelnen Komponenten des Gesamtsystems zu überzeugen.
Ich weiß. Nicht umsonst hatte ich, während Du gesten Deine Antwort schriebst, meinen Post editiert und die Konsolenmeldung in meinen Ausgangspost geschrieben. Aber wie gesagt, diese Meldung ist nicht hilfreich gewesen. Die vom Chrome hingegen schon, zwischen Meldung und Problemlösung lagen keine 2 Minuten.
Die Sache mit dem PHP hätte man in dem Fall auch finden können, indem man die URL direkt aufruft. Zudem sollte die erste Maßnahme nach dem Konfigurieren von PHP sein, mit einer Testdate mit Inhalt
<?php phpinfo();dessen Funktionieren zu bestätigen.Mein Testsystem läuft seit Jahren stabil, das war ja auch nicht das Problem. Ich habe die Ausgangsdatei (die ausschließlich HTML, CSS und JS enthält) einfach über den Dateiexplorer aufgerufen, um zu sehen, wie sie funktioniert. Es handelt sich um ein Plugin ohne jegliche Anleitung und ich wollte die Funktionsweise verstehen. Dann habe ich ein paar Stunden mit Änderungen und Spielereien verbracht (wie gesagt, um das Plugin zu verstehen, der Entwickler hat das eigens so verbreitet, damit der Anwender sich daraus "sein" individuelles Plugin basteln kann/soll). Und hierüber habe ich vergessen, dass ich immer noch "serverlos" damit arbeite...was mir dann beim Einsatz der test.php auf die Füße gefallen ist. Naja, sowas passiert eben...geht die Welt nicht von unter.
Pit
-
-
-
-
Hi,
$('#' + modal + ' .sm_area_bottom').load( "./test.html");
wir sollten vielleicht mal über Pfadangaben im Allgemeinen reden, ich hab das auch nicht gleich gesehen, das da oben, kurzum: Es ist unsinnig. Weil: Diese Pfadangabe auf eine lokale Datei im Dateisystem zeigt, die sich in demselben Verzeichnis befindet wie die Datei... ??? Ja welche eigentlich und welches Verzeichnis??
Aber egal wie die Antwort ausfällt, JavaScript wird auf lokale Dateien im Dateisystem nur dann zugreifen, wenn es mit dem entsprechenden API, nämlich dem File API so programmiert wurde.
Ajax und auch das fetch API greifen nach Webressourcen, eine Pfadangabe like "test.html" ist zwar semantisch auch nicht ganz korrekt aber alle Browser verstehen das wenigstens so, daß sie diese Ressource in demselben virtuellen Verzeichnis zu suchen haben das sie gerade eben auch in ihrer Adresszeile vorfinden. Wobei: Virtuell heißt, auf den Serverpfad bezogen und nicht aufs Dateisystem.
Ansonsten ist und bleibt "test.html" eine relative Pfadangabe mit allen Vor und Nachteilen die damit behaftet sind, bei einem Umzug jedenfalls müssen immer alle Ressourcen mit umziehen die relativ referenziert sind.
Demgegenüber jedoch haben wir ja gerade in Sachen Ajax die Möglichkeit, dienstliche Webressourcen zu zentralisieren, das heißt, daß solche Ressourcen von verschiedenen anderen URL aus nutzbar sind, weil sie eben nur nackte Daten liefern und nicht das ganze HTML drumherum was genauso aussehen muss wie der Referrer. Von daher sind Pfadanganen like
/sun.htmloder/services/sun.phpeine Überlegung wert weil sie dem virtuellen Wurzelverzeichnis angewanzt sind.Schöne Grüße, Freundschaft 😉
-
Hallo,
Aber egal wie die Antwort ausfällt, JavaScript wird auf lokale Dateien im Dateisystem nur dann zugreifen, wenn es mit dem entsprechenden API, nämlich dem File API so programmiert wurde.
nein. httpRequests funktionieren im FF auch ohne Server auf der lokalen Platte.
Gruß
Jürgen-
nein. httpRequests funktionieren im FF auch ohne Server auf der lokalen Platte.
Das hätte ich jetzt gerne mal ein bischen näher erklärt bekommen: Ein Request auf eine Datei im Dateisystem. Was soll denn da bezüglich einer Response passieren? Oder anders ausgedrückt: Was erwartest Du als Inhalt der Reponse?
MfG
-
Hallo,
Was erwartest Du als Inhalt der Reponse?
ich erwarte nicht, ich bekomme (im FF) das gleiche mit und ohne Server.
Gruß
Jürgen-
Hallo,
Was erwartest Du als Inhalt der Reponse?
ich erwarte nicht, ich bekomme (im FF) das gleiche mit und ohne Server.
Ja was denn? Denn Dateiinhalt? Oder wird die Datei ausgeführt?
Wie auch immer, ein HTTPRequest ist ein HTTPRequest und ohne Webserver gibt es weder HTTP Request noch HTTP Response. Das würde ich mal ganz dick ins Archiv übernehmen, alles andere ist Blödsinn.
MfG
-
Hallo,
Ja was denn? Denn Dateiinhalt? Oder wird die Datei ausgeführt?
den Dateiinhalt. In meinem Projekt werden XML-Dateien gelesen.
Wie auch immer, ein HTTPRequest ist ein HTTPRequest und ohne Webserver gibt es weder HTTP Request noch HTTP Response. Das würde ich mal ganz dick ins Archiv übernehmen, alles andere ist Blödsinn
jetzt mäßige dich mal etwas. Nur weil etwas nicht in dein Weltbild passt, heißt das ja nicht, das es das nicht gibt.
Und wenn du es nicht glaubst, lad meinen GPX-Viewer runter und öffne eine von den Beispiel-Html-Dateien im Firefox.
Gruß
Jürgen-
moin,
den Dateiinhalt. In meinem Projekt werden XML-Dateien gelesen.
Und wenn du es nicht glaubst, lad meinen GPX-Viewer runter und öffne eine von den Beispiel-Html-Dateien im Firefox.
Eigentlich habe ich ja um eine Erklärung gebeten. Wäre ja auch fürs Archiv interessant.
Kennt Dein Dateisystem HTTP? Hab ich bei meinem noch nicht festgestellt.
MfG
-
Hallo,
da gibt es nichts zu erklären. Der
XMLHttpRequestfunktioniert im FF auch ohnehttp. Als ich mein Projekt vor ca. 10 Jahren gestartet habe, ging es sogar noch in allen Browsern. Probier es einfach aus.Gruß
Jürgen -
Kennt Dein Dateisystem HTTP? Hab ich bei meinem noch nicht festgestellt.
Nein, aber Jörg hat trotzdem Recht. Öffnet man eine lokale Datei mit dem Browser sieht man in der Adresszeile
file://, wo sonsthttps://steht. Das heißt, wir haben es hier offensichtlich nicht mit einem HTTP-URL zu tun, sondern mit einem file URI und damit können Browser auch umgehen, deswegen funktioniert Jörgs Anwendung auch ohne HTTP-Server.-
Kennt Dein Dateisystem HTTP? Hab ich bei meinem noch nicht festgestellt.
Nein, aber Jörg hat trotzdem Recht. Öffnet man eine lokale Datei mit dem Browser sieht man in der Adresszeile
file://, wo sonsthttps://steht. Das heißt, wir haben es hier offensichtlich nicht mit einem HTTP-URL zu tun, sondern mit einem file URI und damit können Browser auch umgehen, deswegen funktioniert Jörgs Anwendung auch ohne HTTP-Server.Ja, das mag schon sein, aber wer bestimmt denn nun, was mit der Datei zu tun ist? Ein Webserver wird konfiguriert ob er bspw. den Inhalt der Datei zurückgibt oder das Ergebnis einer Ausführung dieser Datei. Was macht der Browser wenn er im FS auf eine ausführbare Datei trifft?
Nichtsdestoweniger geht das alles an HTTP vorbei. Diese Erkenntniss ist wichtig, wenn man URLs nach dem Schema
./index.phpnotiert und daran bestimmte Erwartungshaltungen knüpft. Somit begeht man einen systematischen Fehler, wenn man in diesem Fall davon ausgeht, daß ein HTTP Request erfolgt.Deswegen ja meine Notizn zum Thema Pfadangaben.
MfG
-
Somit begeht man einen systematischen Fehler, wenn man in diesem Fall davon ausgeht, daß ein HTTP Request erfolgt.
XMLHttpRequestist auch ein Kandidat für den blödesten Namen im JavaScript-Land, ich stelle mir gerade den Dialog im Komitee bei der Namesvergabe vor:Mensch 1: Ist es an XML gekoppelt?
Mensch 2: Nein.
Mensch 1: Ist es an HTTP gekoppelt?
Mensch 2: Nein.
Mensch 1: Dann nennen wir es XMLHttpRequest.
Mensch 2: Hörst du mir zu?
Mensch 1: Gut, dann ist das einstimmig angenommen. Nächstes Thema.
Mensch 2: ┌∩┐(ಠ_ಠ)┌∩┐-
Somit begeht man einen systematischen Fehler, wenn man in diesem Fall davon ausgeht, daß ein HTTP Request erfolgt.
XMLHttpRequestist auch ein Kandidat für den blödesten Namen im JavaScript-Land, ich stelle mir gerade den Dialog im Komitee bei der Namesvergabe vor:Mensch 1: Ist es an XML gekoppelt?
Mensch 2: Nein.
Mensch 1: Ist es an HTTP gekoppelt?
Mensch 2: Nein.
Mensch 1: Dann nennen wir es XMLHttpRequest.
Mensch 2: Hörst du mir zu?
Mensch 1: Gut, dann ist das einstimmig angenommen. Nächstes Thema.
Mensch 2: ┌∩┐(ಠ_ಠ)┌∩┐Ja sehe ich genauso. Und jedesmal nach Groß-/Kleinschreibung gucken nervt auch 😉
Da das Teil im Prinzip nur eine weitere Instanz des Browsers bzw. UserAgent ist, würde man als Prototyp einen Solchen erwarten und so
var Agent = new Browser()oder sovar Agent = new UserAgent()kann dann jeder seine Instanz nennen wie er lustig ist.Druschba!
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Moin Pit,
was spricht eigentlich dagegen, direkt XMLHttpRequest zu verwenden?
Hi Robert,
am meisten, dass ich mich damit überhaupt nicht auskenne 😉
Pit
-
Moin Pit,
deshalb habe ich dir gleich den Link zur Doku spendiert 😉
Viele Grüße
Robert
-
-
@@Robert B.
was spricht eigentlich dagegen, direkt XMLHttpRequest zu verwenden?
Das Fetch-API.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Hallo @Gunnar Bittersmann,
Das Fetch-API.
Kommt darauf an welche Browser man unterstützen möchte.
Viele Grüße
Robert-
@@Robert B.
Das Fetch-API.
Kommt darauf an welche Browser man unterstützen möchte.
Nein. Es kommt darauf an, on man progressive enhancement vestanden hat.
Ein Link ist ein Link ist ein Link. Das ist die Grundlage. In unterstützenden Browsern kann man Links zu Inhalten dadurch ersetzen, dass diese Inhalte ohne notwendige Nutzerinteraktion gleich dynamisch geladen werden.
Außerdem: grün, soweit das Auge reicht. (Außer denen, die aus irgendeinem Grund einen alten IE anstatt bspw. Edge verwenden.)
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory-
Außerdem: grün, soweit das Auge reicht. (Außer denen, die aus irgendeinem Grund einen alten IE anstatt bspw. Edge verwenden.)
Könnte mit dem kleinen Detail zu tun haben, dass Windows 7 immer noch weit verbreitet ist. Da von einem alten IE zu sprechen, wäre falsch. IE 11 ist da quasi bleeding edge.
Je nach Zielgruppe dann z.B. 10% der Clients die blanke Response vor den Latz zu knallen, kann nicht Dein Ernst sein. Also müsste man für progressive Enhancement hier gesonderte Energie investieren, damit die Response in dem Fall dann doch komplett ist. Ernsthaft?
Progressive enhancement in allen Ehren, aber in dem Fall ist das m.E. kompletter Overkill.
Empfehl halt einen Polyfill und gut ist.
-
@@Mitleser
Empfehl halt einen Polyfill und gut ist.
Steht auf der von mir verlinkten MDN-Seite.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory -
Könnte mit dem kleinen Detail zu tun haben, dass Windows 7 immer noch weit verbreitet ist.
Hier 😀
-
-
-
-
-