iFrame Alternative: Dateien laden mit Ajax?
0 
suit
0 0 
Matti Maekitalo
0 suit
0
1
iFrame Alternative: Dateien laden mit Ajax?
Hi,
ich habe folgenden Div, in den ich kleine Inhalte reinladen möchte, ohne dass die Seite neu geladen wird:
<div id="texte">
</div>
Habe mehrere Unterseiten (u1-file.html, u2-file.html) in denen sich hauptsächlich Texte befinden. Habe mir erst überlegt ob ich jetzt einfach einen iFrame in den Div oben packe und so die Inhalte der Dateien anzeigen lasse.
Aber irgendwie finde ich iFrames so altmodisch, und unprofessionell. Ist es möglich per Ajax Inhalte der Unterseiten abzurufen und diese dann in diesen DIV zu packen (z.B. mit "innerHTML" nach Abruf der Daten)?
Ich bräuchte mal einen Ansatz von euch, habe noch nie mit Ajax gearbeitet, kenne mich aber recht gut mit Javascript aus. Habe im Internet nur Anleitungen zu jQuery gefunden. Ich will mir aber jetzt nicht gleich wegen dem kleinen Problem die komplette Library von denen auf meiner Seite draufladen, weil ich bis jetzt alle Javascript Files selber geschrieben habe.
Grüße,
nic
-
Aber irgendwie finde ich iFrames so altmodisch, und unprofessionell.
Für diesen Zweck ja.
Ist es möglich per Ajax Inhalte der Unterseiten abzurufen und diese dann in diesen DIV zu packen (z.B. mit "innerHTML" nach Abruf der Daten)?
Ja - aber das als alleinige Lösung ist genauso unprofessionell - das nachladen oder ersetzen von Inhalten mittels Ajax sollte stehts als Ergänzung fungieren.
Ich will mir aber jetzt nicht gleich wegen dem kleinen Problem die komplette Library von denen auf meiner Seite draufladen, weil ich bis jetzt alle Javascript Files selber geschrieben habe.
Dann setze dich mit "XMLHttpRequest" auseinander - dass du hierzu nichts gefunden hast ist beschämend, sogar die deutschsprachige Wikipedia hat einen Artikel (mit Codebeispiel) hierzu.
Eine Bibliothek zu verwenden spart dir in diesem Kontext aber extrem viel Arbeit und Zeit. Diese Zeit kannst du sinnvoll in die nicht-JavaScript-Fähigkeiten der Site stecken.
-
Ja - aber das als alleinige Lösung ist genauso unprofessionell - das nachladen oder ersetzen von Inhalten mittels Ajax sollte stehts als Ergänzung fungieren.
Hm, was bleibt dann noch übrig außer iFrames und Ajax?
-
Tach auch.
Ja - aber das als alleinige Lösung ist genauso unprofessionell - das nachladen oder ersetzen von Inhalten mittels Ajax sollte stehts als Ergänzung fungieren.
Hm, was bleibt dann noch übrig außer iFrames und Ajax?
AJAX als default-Variante und normale Links als Backup-Lösung, falls jemand JS deaktiviert hat.
Bis die Tage,
Matti-
AJAX als default-Variante und normale Links als Backup-Lösung, falls jemand JS deaktiviert hat.
Ich würds eher mit "normale Links als default-Variante" und Ajax als Eye-Candy falls jemand JS aktiviert hat bezeichnen ;)
Damit möchte ich jetzt garnicht darauf hinaus, dass so viele Leute JavaScript deaktiviert haben - in meiner Statistik haben mittlerweile nur noch etwa 2,5 % der echten Besucher JavaScript deaktiviert.
Aber es muss nur mal etwas schiefgehen - ein JavaScript-Fehler der die Ausführung anderer Scripte unterbindet, dann geht garnix mehr. z.B. in einer Drittanbietersoftware, bei einem Werbeprogramm oder sonstwas - das passiert sogar relativ häufig, dass da jemand pfuscht.
-
-
Hi,
Hm, was bleibt dann noch übrig außer iFrames und Ajax?
Ein ganz herkömmlicher Seitenaufbau, der „echte“, vollständige Dokumente untereinander verlinkt. Das ist bewährte Technik, die problemlos funktioniert, und kaum von Umgebungsbedingungen abhängig ist.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
-
-
[latex]Mae govannen![/latex]
Ich will mir aber jetzt nicht gleich wegen dem kleinen Problem die komplette Library von denen auf meiner Seite draufladen, weil ich bis jetzt alle Javascript Files selber geschrieben habe.
Eine Bibliothek zu verwenden spart dir in diesem Kontext aber extrem viel Arbeit und Zeit. Diese Zeit kannst du sinnvoll in die nicht-JavaScript-Fähigkeiten der Site stecken.
Das schon. Allerdings ist dann nicht jQuery die richtige Wahl, sondern ein "Standalone-Script", das auch wirklich nur XMLHttpRequest macht.
Nur für ein wenig XMLHttpRequest 72k Code einzubinden ist absolut sinnfrei; insbesondere, wenn er alles Andere bereits selbst geschrienben hat.Wenn die Funktionen von Cybaer laut jemandem hier im Forum schon "Spatzen-Kanonen" sind/sein sollen - dann ist/wäre jQuery _nur_ für diese eine Funktionalität eine Spatzen-Atombombe.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
in Richtung "Mess up the Web".(suit)
SelfHTML-Forum-Stylesheet-
Das schon. Allerdings ist dann nicht jQuery die richtige Wahl, sondern ein "Standalone-Script", das auch wirklich nur XMLHttpRequest macht.
Nur für ein wenig XMLHttpRequest 72k Code einzubinden ist absolut sinnfrei; insbesondere, wenn er alles Andere bereits selbst geschrienben hat.jQuery hat minified und komprimiert < 25 kB - das ist im vergleich zu den Tonnen an Bildern und Videos die man heutzutage auf Webseiten einbindet ziemlich vernachlässigbar.
Wenn die Funktionen von Cybaer laut jemandem hier im Forum schon "Spatzen-Kanonen" sind/sein sollen - dann ist/wäre jQuery _nur_ für diese eine Funktionalität eine Spatzen-Atombombe.
Natürlich, wenn man das Framework sonst nicht braucht, ist es ein Overkill - aber mit einem einfach zu benutzenden Framework bleibt es dann nicht bei ein paar einzelnen Requests ;)
Bei einer durchschnittlichen Hotel-Website spart man mit jQuery schon massig.
Ein Datepicker, Formularvalidierung, Lightbox usw - wenn man das alles per Hand schreibt, vergehen Ewigkeiten und man hat nicht wirklich signifikant weniger Code.
-
[latex]Mae govannen![/latex]
Das schon. Allerdings ist dann nicht jQuery die richtige Wahl, sondern ein "Standalone-Script", das auch wirklich nur XMLHttpRequest macht.
Nur für ein wenig XMLHttpRequest 72k Code einzubinden ist absolut sinnfrei; insbesondere, wenn er alles Andere bereits selbst geschrienben hat.jQuery hat minified und komprimiert < 25 kB - das ist im vergleich zu den Tonnen an Bildern und Videos die man heutzutage auf Webseiten einbindet ziemlich vernachlässigbar.
Deshalb müssen vom JS-Parser trotzdem 72k verarbeitet werden. Die Übertragungsgröße ist völlig unerheblich.
Wenn die Funktionen von Cybaer laut jemandem hier im Forum schon "Spatzen-Kanonen" sind/sein sollen - dann ist/wäre jQuery _nur_ für diese eine Funktionalität eine Spatzen-Atombombe.
Natürlich, wenn man das Framework sonst nicht braucht, ist es ein Overkill - aber mit einem einfach zu benutzenden Framework bleibt es dann nicht bei ein paar einzelnen Requests ;)
Das kann natürlich passieren. Meine Bemerkung war auch ausschließlich davon ausgehend, daß er sonst alles schon geschrieben hat (und auch nicht alles aufs Framework umschreiben will).
Bei einer durchschnittlichen Hotel-Website spart man mit jQuery schon massig.
Ein Datepicker, Formularvalidierung, Lightbox usw - wenn man das alles per Hand schreibt, vergehen Ewigkeiten und man hat nicht wirklich signifikant weniger Code.
Klar. Und das Grundwissen, um die ganzen teilweise bösen Fallen der browserübergreifenden Programmierung zu kennen, muß man auch erst mal haben.
Mit einem vernünftigen Framework kann man vieles erleichtern. Bis dahin muß halt auf jQuery und Andere zurückgegriffen werden.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
in Richtung "Mess up the Web".(suit)
SelfHTML-Forum-Stylesheet-
Deshalb müssen vom JS-Parser trotzdem 72k verarbeitet werden. Die Übertragungsgröße ist völlig unerheblich.
Das ist richtig, aber JavaScript-Engines sind heutzutage so schnell, dass das kaum ins Gewicht fällt - selbst auf Mobiltelefonen :)
-
-
-
-