javascript funktion .load html -> in div-Element
0 
Felix Riesterer
0 
Rolf B
0 0 Felix Riesterer
0 0 0 Rolf B
javascript funktion .load html -> in div-Element
Gunnar BittersmannHallo liebe Gemeinde!
ich muss als erstes sagen, dass ich gerade wieder anfange mit der HTML-Programmierung ( meine letzten Schritte sind JAHRE her ). Nachdem mir hier im Formum schon wunderbar mit einem Problem der UTF-8 Kodierung geholfen wurde stehe ich nun vor einem neuen Problem.
Wie oben schon gesagt habe ich vor ewigkeiten schonmal HTML geschrieben. Zu jener Zeit wurde noch eifrig mit FRAMES gearbeitet. Nun, wo ich wieder angefangen habe stelle ich Fest, dass das so nicht mehr gern gesehen ist und auch nicht mehr üblich ist. Also habe ich mich alternativ mit <div> beschäftigt.
Mein Ziel ist es, einen <div id="content"> mittels javascript Function durch die Auswahl aus einem Navi Menü neu zu füllen. Meine Frage ist, ist dies überhaubt möglich ohne das ich den Browser zwinge die gesamt Seite neu zu laden?
Die Function schein aufgerufen zu werden, dies habe ich mittels Alarm-Function getestet. Leider wird das <div> nicht aktualisiert, oder wird es eventuell aktualisiert und der Browser weiß nur nichts davon?
Ich möchte halt den Inhalt des <div> in Abhägigkeit der Menüauswahl ändern ohne immer die ganze Seite neu laden zu müssen.
Hier mein Code:
<?php header('Content-type: text/html; charset=utf-8'); ?>
<!doctype html>
<html lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html" charset=utf-8" />
<script type="text/javascript">
function reload () {
$( "#content" ).load( "test.html" );
};
</script>
</head>
<body>
<div id="menu">
<ul>
<li><a href="javascript:reload()">Home</a></li>
<li><a href="#">Kalender</a></li>
</ul>
</div>
<div id="content">
Hallo
</div>
</body>
</html>
test.html ist liegt im selben Ordner wie die index.php und enthält zum testen einfach nur das Wort: Funktioniert
Ich hoffe ihr könnt mein Anliegen verstehen und bitte um Eure Hilfe!
Vielen Dank und Grüße Lars
-
Lieber Lars,
Mein Ziel ist es, einen <div id="content"> mittels javascript Function durch die Auswahl aus einem Navi Menü neu zu füllen.
dazu habe ich zwei Dinge:
- Du möchtest anstelle von <div id="content"> lieber ein <main>.
- Ohne JavaScript ist die Benutzung Deiner Seite also völlig unmöglich. Ist das so gewollt, und wenn ja, warum?
Natürlich kann man zu 2. argumentieren, dass fast keine Seitenbesucher mehr ohne JavaScript daher kommen, aber inwiefern trennst Du dann Inhalt (Marku, HTML-Code) von Programmlogik (JavaScript)? Ich liebäugle noch sehr mit der Ansicht, dass die Inhalte einer Seite grundsätzlich ohne JavaScript erreichbar sein müssen. Auch wenn sie dann "weniger schön" dargestellt oder benutzbar sind.
Meine Frage ist, ist dies überhaubt möglich ohne das ich den Browser zwinge die gesamt Seite neu zu laden?
Ja, undzwar genau dann, wenn Du alle Inhalte "irgendwie" schon in dieser einen Seite geladen hast. Das ist übrigens auch das Konzept hinter den "one-pager"-Seiten. Allerdings sind die einfach eine lange Scroll-Angelegenheit. Aber genau hier könntest Du ansetzen und Deine Inhalte eben durch Verweise "austauschen". Dazu bräuchtest Du noch nicht einmal JavaScript, sondern könntest rein mit CSS das gleiche erreichen:
<main> <article id="home">...</article> <article id="contact">...</article> <article id="privacy-policy">...</article> </main> <nav> <h2>Navigation</h2> <ul> <li><a href="#home">Home</a></li> <li><a href="#contact">Contact Us</a></li> <li><a href="#privacy-policy">Our Privacy Policy</a></li> </ul> </nav>Und in Deinem CSS-Code müsste dann in etwa das hier stehen:
article { display: none; } article:target { display: block; }Die Function schein aufgerufen zu werden, dies habe ich mittels Alarm-Function getestet. Leider wird das <div> nicht aktualisiert, oder wird es eventuell aktualisiert und der Browser weiß nur nichts davon?
Hehe, willkommen beim Schreiben von JavaScript. Du nanntest HTML als Dein Vorwissen. JavaScript ist eine ergänzende Technologie, die aus dem Bereich der Programmiersprachen kommt. HTML ist keine Programmiersprache.
Ich möchte halt den Inhalt des <div> in Abhägigkeit der Menüauswahl ändern ohne immer die ganze Seite neu laden zu müssen.
Das geht schon ohne JavaScript. Siehe oben.
<li><a href="javascript:reload()">Home</a></li>Keine gute Idee. Du notierst JavaScript-Code in Deinem HTML-Dokument. Ohne JavaScript sollte da etwas anderes passieren. Also muss Dein JavaScript-Programm diese Links "kapern" und mit Deiner dynamischen Arbeitsweise versehen. Das nennt man dann wohl unobtrusive... also unaufdringlich. So machst Du die Funktionalität (lies: die Benutzbarkeit) Deiner Seite kaputt, weil ohne JavaScript nichts mehr geht (und aktuell mit JavaScript auch nicht).
<li><a href="#">Kalender</a></li>Siehst Du was ich meine? Hier kommt kein Kalender.
test.html ist liegt im selben Ordner wie die index.php und enthält zum testen einfach nur das Wort: Funktioniert
Oh weh, mit PHP hantierst Du auch noch? Wozu denn? Was leistet Dein PHP-Script, was Dein HTML nicht kann? Was für eine Programmlogik leistet hier PHP? Nicht, dass ich Dir ausreden möchte, den Umgang mit PHP zu erlernen, aber was genau tust Du hier?
Für das obige Beispiel von mir könnte ich mir vorstellen, dass Dein PHP-Script einzelne HTML-Dateien zu einem gemeinsamen Dokument zusammenführt. Dabei könnten die einzelnen Seiten in Dateien wie
home.html,contact.htmloderprivacy-policy.htmlstehen, und das PHP-Script baut aus ihrem Dateinamen entsprechendeid-Werte (siehe Beispiel oben) für diearticle-Elemente, welche den HTML-Code aus dem jeweiligenbody-Element der HTML-Dateien erhalten.Eine solche Lösung wäre gut skalierbar, da Du für weitere Seiten einfach (wirklich "einfach"!) weitere HTML-Dateien in das jeweilige Verzeichnis ablegst, die dann von PHP gefunden und auf dieselbe Weise eingebunden werden.
Wenn Du später einmal eine Unterstützung für Mehrsprachigkeit obendrauf satteln willst, ist auch das mit diesem Vorgehen zu machen.
Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
2. Ohne JavaScript ist die Benutzung Deiner Seite also völlig unmöglich. Ist das so gewollt, und wenn ja, warum?
Natürlich kann man zu 2. argumentieren, dass fast keine Seitenbesucher mehr ohne JavaScript daher kommen
Kann man? Von einigen JavaScript-Deaktivierern abgesehen: jeder Seitenbesucher kommt ohne JavaScript daher, solange das JavaScript nicht geladen und ausgeführt wurde.
Und das passiert häufiger als man denkt. Fahr mal mit der Bahn durch BrandEDGEburg! Und eingebundene fehlerhafte Fremd-Scripte können die Ausführung des eigenen JavaScripts verhindern.
Ich liebäugle noch sehr mit der Ansicht, dass die Inhalte einer Seite grundsätzlich ohne JavaScript erreichbar sein müssen.
Noch? Die Liebäugelei solltest du dir erhalten. JavaScript ist fragil; man kann sich darauf nicht verlassen.
Meine Frage ist, ist dies überhaubt möglich ohne das ich den Browser zwinge die gesamt Seite neu zu laden?
Ja, undzwar genau dann, wenn Du alle Inhalte "irgendwie" schon in dieser einen Seite geladen hast.
„Genau dann, wenn“ trifft nicht zu. Man kann Inhalte mit JavaScript/AJAX auch nachladen.
<main> <article id="home">...</article> <article id="contact">...</article> <article id="privacy-policy">...</article> </main>Ich glaube nicht, dass
articlehier das passende Element ist. Ich tendiere zusectionoderdiv.Was auch ginge:
<main id="home">...</main> <main id="contact" hidden="">...</main> <main id="privacy-policy" hidden="">...</main>Allerdings braucht man dann zum Umschalten der Sichtbarkeit (des
hidden-Attributs) JavaScript.Und was man bei einer JavaScript-Lösung auf keinen Fall vergessen sollte: Über das History-API den URL in der Adresszeile ändern, damit die Seite als Lesezeichen gesetzt und mit anderen geteilt werden kann. Und damit der Zurück-Buttons des Browsers funktioniert.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
Ich liebäugle noch sehr mit der Ansicht, dass die Inhalte einer Seite grundsätzlich ohne JavaScript erreichbar sein müssen.
Noch? Die Liebäugelei solltest du dir erhalten. JavaScript ist fragil; man kann sich darauf nicht verlassen.
ich baue meine Seiten noch immer so, dass ihre Inhalte ohne JavaScript zu 100% genutzt werden können. Ausnahme mein R-Quiz, aber das ist ja klar. Im Admin-Bereich allerdings setze ich JavaScript voraus, das zugehörige Login-Formular ist ohne JavaScript nicht erreichbar.
Ich glaube nicht, dass
articlehier das passende Element ist. Ich tendiere zusectionoderdiv.Ach ja, die Frage, ob man
sectionals Elternelement vonarticleverwendet, oder umgekehrt. Wenn der "Aufsatz" (article) zu "Datenschutzrichtlinie" ein Teilsegment (section) der Seite ist, was ist dann das zu bevorzugende Element? Beide Lösungen haben ihren Sinn. Als Kapitel (section) innerhalb eines Aufsatzes oder Blogbeitrag (article) sehe ich dann aber eine klarere Strukturierung mitarticleals Elternelement.Was auch ginge:
<main id="home">...</main> <main id="contact" hidden="">...</main> <main id="privacy-policy" hidden="">...</main>Grundsätzlich finde ich das
hidden-Attribut sehr chic, jedoch wie Du richtig anmerkst, bedarf es dazu JavaScript:Allerdings braucht man dann zum Umschalten der Sichtbarkeit (des
hidden-Attributs) JavaScript.Daher fand ich meine CSS-basierte Lösung geschickter und ebenso semantisch/SEO/ARIA/WTF.
Und was man bei einer JavaScript-Lösung auf keinen Fall vergessen sollte: Über das History-API den URL in der Adresszeile ändern, damit die Seite als Lesezeichen gesetzt und mit anderen geteilt werden kann. Und damit der Zurück-Buttons des Browsers funktioniert.
Das wäre in meiner rein CSS-basierten Lösung bereits inklusive. Ist sie damit nicht die überlegenere Lösung?
Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
Ich glaube nicht, dass
articlehier das passende Element ist. Ich tendiere zusectionoderdiv.Ach ja, die Frage, ob man
sectionals Elternelement vonarticleverwendet, oder umgekehrt.Oder in dem Fall weder das eine noch das andere.
Hier wird ja (im Normalfall) nur jeweils einer der Bereiche angezeigt, welcher dann den Hauptinhalt der Seite ausmacht und nicht nur einen Teil davon.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann -
@@Felix Riesterer
Das wäre in meiner rein CSS-basierten Lösung bereits inklusive. Ist sie damit nicht die überlegenere Lösung?
Nein. Der Schwachpunkt der Lösung mit seiteninternen Ankern ist, dass nicht nur über
:targetdie Sichtbarkeit geregelt wird, sondern eben auch der Anker angesprungen wird. Das heißt: die Seite springt vom Menü weg zu dem angewählten Bereich. Zu sehen bei mehr Inhalt.Das dürfte einer mittleren UX-Katastrophe nahekommen.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
-
@@Felix Riesterer
Und in Deinem CSS-Code müsste dann in etwa das hier stehen:
article { display: none; } article:target { display: block; }In etwa, aber andersrum:
article:not(:target) { display: none }Sonst ist in Browsern, die
:targetnicht unterstützen, nichts zu sehen.LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Lieber Gunnar,
Sonst ist in Browsern, die
:targetnicht unterstützen, nichts zu sehen.und welche betriffst das noch?
Liebe Grüße,
Felix Riesterer.
-
@@Felix Riesterer
Sonst ist in Browsern, die
:targetnicht unterstützen, nichts zu sehen.Ist mir schnuppe. Ich unterstütze jeden Browser – und optimiere für keinen, wie Jeremy Keith immer zu sagen pflegt.
Progressive enhancement heißt, die Grundfunktionalität für alle bereitzustellen – und das heißt in dem Fall, dass man den Inhalt in allen Browsern lesen kann. In
:targetoder:not()nicht unterstützenden Browsern wäre dann halt der gesamte Inhalt zu sehen – allemal besser als kein Inhalt.LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
-
Hallo Ingrid,
article { display: none; } article:target { display: block; }ich habe das gerade ausprobiert. Dabei stellt sich das Problem, dass der Aufruf der Seite ohne Fragment-Identifier, also ohne
#home,#contactoder#privacy-policyin der URL, keinen Inhalt liefert, bis man einen der Links geklickt hat. Auf die Schnelle weiß ich jetzt aber keine Lösung dafür.Wenn man den
home-Abschnitt grundsätzlich sichtbar macht, wie will man es bei einem direkt angewählten anderen Bereich rein mit CSS wieder unsichtbar machen?Liebe Grüße,
Felix Riesterer.
-
Hallo Felix,
wenn der #home Abschnitt der letzte im HTML ist und alle Artikel Kind des gleichen Containers sind, kann man vielleicht mit dem Geschwisterselektor was machen.
article { display: none; } article:target:not(#home), #home { display: block; } article:target ~ #home { display: none; }Ggf. muss man die Spezifität noch etwas tweaken.
Ob das ein Ergebnis ist, bei dem Semantik und Accessibility stimmen, weiß ich aber nicht.
Rolf
--
sumpsi - posui - clusi -
@@Felix Riesterer
Wenn man den
home-Abschnitt grundsätzlich sichtbar macht, wie will man es bei einem direkt angewählten anderen Bereich rein mit CSS wieder unsichtbar machen?Ich behaupte mal ganz keck: gar nicht.
Man kann initial den letzten Abschnitt sichtbar machen, indem man nur
:target:not(:last-of-type)ausblendet. Der letzter Abschnitt wird ausgeblendet, wenn ein anderer davor angewählt ist::target ~ :last-of-type.☞ Codepen 🇫🇷
Initial den letzten Abschnitt sichtbar machen ist aber sicher nicht das, was man will. Den ersten Abschnitt ans Ende stellen ist auch keine Lösung; dann ist die Seite kaputt, wenn CSS nicht interpretiert wird.
Man muss deine Frage Ist meine rein CSS-basierten Lösung nicht die überlegenere Lösung? wohl mit einem klaren Nein beantworten.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
@@Gunnar Bittersmann
Wenn man den
home-Abschnitt grundsätzlich sichtbar macht, wie will man es bei einem direkt angewählten anderen Bereich rein mit CSS wieder unsichtbar machen?Ich behaupte mal ganz keck: gar nicht.
Ich nehm’s zurück und behaupte das Gegenteil.
Der Trick ist, alle Bereiche übereinanderzulegen – in dieselbe Grid-Zelle – und den ersten Bereich nicht auszublenden, sondern alle anderen – und das nur in Grid unterstützenden Browsern (feature query
@supports (display: grid)).☞ Grid-Variante 🇫🇷
Man muss deine Frage Ist meine rein CSS-basierten Lösung nicht die überlegenere Lösung? wohl mit einem klaren Nein beantworten.
Das nehme ich allerdings nicht zurück. Aus Gründen.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
@@Gunnar Bittersmann
Der Trick ist, alle Bereiche übereinanderzulegen – in dieselbe Grid-Zelle – und den ersten Bereich nicht auszublenden, sondern alle anderen – und das nur in Grid unterstützenden Browsern (feature query
@supports (display: grid)).Braucht man gar nicht, wenn man nicht mit
display: noneausblendet, sondern den jeweils anzuzeigenden Bereich mitz-indexnach vorne holt. Dann sollte das auch in IE 10 und 11 funktionieren, die Grid (eingeschränkt; mit Präfix) unterstützen, aber nicht@supports.☞ Grid-Variante 2 🇫🇷 (ungetestet in IE)
„Funktionieren“ mit der Einschränkung, dass die gesamte Lösung aus Gründen nicht funktioniert.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
@@Gunnar Bittersmann
Braucht man gar nicht, wenn man nicht mit
display: noneausblendet, sondern den jeweils anzuzeigenden Bereich mitz-indexnach vorne holt.Was auch keine so gute Idee ist. Vor Screenreadern wären die Bereiche nicht versteckt; es würde etwas vorgelesen werden, was gar nicht auf dem Bildschirm zu sehen ist. Nicht machen!
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
-
Hallo Gunnar,
wenn CSS nicht interpretiert wird.
diesen Satz habe ich jetzt schon ein paar mal gelesen und ich frage mich: Wie? Außer, dass das CSS extern ist und nicht geladen wird. Dem kann man aber begegnen, indem man die für das Einblenden relevanten CSS Teile in den <head> der Seite verlegt; so viel ist das ja nicht.
Rolf
--
sumpsi - posui - clusi-
@@Rolf B
wenn CSS nicht interpretiert wird.
diesen Satz habe ich jetzt schon ein paar mal gelesen und ich frage mich: Wie? Außer, dass das CSS extern ist und nicht geladen wird.
- Der Nutzer stellt CSS in ihrem Browser komplett aus.
- Der Browser ist ein Textbrowser wie Lynx.
Fundamentale Dinge wie
display: nonewird vielleicht auch ein Textbrowser interpretieren? Änderungen von z-Indizes sicherlich nicht.LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Hallo Gunnar,
ok, das kann ich tatsächlich im Brandfuchs via Menü tun und in Chrome via Extension. Aber warum sollte man das tun, außer um zu testen wie die Seite aussieht wenn eine CSS Datei nicht ankommt? Und warum sollte man das dann SO tun, und die Inlinestile mit töten, statt die CSS Datei umzubenennen?
Lync ist dagegen was anderes. Aber wer verwendet den noch? Selbst als Testbasis für sehbehinderte Menschen wird er nicht mehr empfohlen (sagt Wikipedia).
Rolf
--
sumpsi - posui - clusi-
@@Rolf B
Aber warum sollte man das tun …?
Aber wer verwendet den noch?Ich finde die Fragen müßig. Nutzer, die das tun oder den Browser verwenden, auszuschließen ist das Gegenteil von inklusivem Design.
HTML ist die Grundlage; eine Seite sollte mit ausschließlich HTML schon funktionieren. Styling ist progressive enhancement.
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
-
-
-
-
Hallo Lars,
wenn deine Datei auf dem Server exakt so aussieht wie gezeigt, kann es nicht funktionieren.
$('#content').load('test.html')ist ein jQuery Aufruf, dazu musst Du jQuery einbinden. In heutigen Browsern braucht man für Ajax-Calls aber nicht mehr unbedingt jQuery. Schau Dir mal fetch an (für Support des Internet Explorer brauchst Du einen Polyfill für Fetch und Promise, könntest aber auch sagen: für den alten Schinken biete ich das nicht an und bleibe bei einfachem HTML).Es gibt einige Webseiten, die als SPA (Single Page Application) konzipiert sind und ohne JavaScript nicht benutzt werden können. Es ist dann aber sinnvoll, eine Fallback-Webseite bereitzustellen, die ohne JavaScript funktioniert und ggf. auch anders aussieht (Beispiel: schalte JavaScript ab und rufe Google auf. Sogar für Google Mail gibt es eine HTML-Variante ohne JS).
PL hat neulich das Konzept angesprochen und mit mir diskutiert, wie man eine normale Webseite als Progressive Enhancement in eine Ajax-Seite umwandeln kann, ohne dass serverseitig irgendwas zu tun ist. Es gibt viele Wege, wie man das tun kann, es gibt auch Möglichkeiten, wie man serverseitig Optimierungen für den Ajax-Zweig vorsehen kann, vielleicht liest Du Dir das entsprechende Thema einfach mal durch.
https://forum.selfhtml.org/self/2019/feb/22/domparser-und-progressive-enhancement/1743135
Wenn Du so etwas tun willst, brauchst Du allerdings gute JavaScript Kenntnisse.
Rolf
--
sumpsi - posui - clusi -
Hallo!
Hui, hier hab ich ja gleich eine kleine Diskusionsrunde ausgelöst 😀
Ich habe mir nun alles aufmerksam durch gelesen und werde mir, sobald ich ein wenig Zeit habe auch die Themen "target" und "fetch" näher ansehen.Grob überflogen habe ich diese schon und es sind interessante Ansätze für mich zu sehen.
Ja, undzwar genau dann, wenn Du alle Inhalte "irgendwie" schon in dieser einen Seite geladen hast. Das ist übrigens auch das Konzept hinter den "one-pager"-Seiten.
Das ist ja eines meiner "Probleme" ich kann nicht gleich den gesamten Seiteninhalt laden. Das ist auch der Grund warum ich php benutze wie du ja schon angemerkt hast. Mein Inhalte werden via php dynamisch generiert, da sie zum grösten Teil aus einer Datenbank kommen.
vielleicht hätte ich das gleich im ersten Post schon schreiben sollen!? 😟
Zeil von mir ist es z.b. nach der Auswahl eines Menüeintrages den enstprechenden Inhalt in einem <div> ( oder <main> oder was auch immer ) anzuzeigen. Diese könnte ich ja noch für alle Menü-Einträge "vor laden" und dann mit target/fetch arbeiten. Aber danach steht dann z.B. in einem <div> ein Listenfeld mit einer Anzahl von Herstellern. Nun möchte ich den Inhalt eines weiteren <div> nach der Auswahl eines Herstellers generieren und ausgeben ( z.b. mit dessen Artikeln ) -> Diese Daten kommen auch wieder aus der Datenbank. Da ich am Anfang natürlich nicht weiß, welcher Hersteller ausgewählt wurde ist es schwer die Inhalte "vor-zu-laden" !?
Ich habe das ganze ja schon teilweise zum laufen bekommen, in dem ich meiner eigenen Seite, nach einer Auswahl aus dem Listenelement, dessen ID mit gegeben habe und dann wieder die ganze Seite entsprechend aufgebaut habe. Dies kommt mir aber sehr umständlich vor, da ich immer wieder die gesamte Seite aufbauen muss!?
In den alten Frames Zeiten hätte ich in diesem Falle nur die html-Seite in dem entsprechendem Frame mit dem Parameter neu geladen.
Klar würde ich im Moment lieber ohne java auskommen, was ja auch einer der Gründe war das ich mich an Euch gewendet habe!
Ich hoffe ich konnte meine Absichten nun etwas deutlicher dar stellen.
Lg Lars
-
Lieber Lars,
Das ist ja eines meiner "Probleme" ich kann nicht gleich den gesamten Seiteninhalt laden. Das ist auch der Grund warum ich php benutze wie du ja schon angemerkt hast. Mein Inhalte werden via php dynamisch generiert, da sie zum grösten Teil aus einer Datenbank kommen.
und wo ist nun das Problem? Warum willst Du nicht die Seite selbst neu laden müssen? Jetzt rück' doch mal wirklich mit dem wichtigen Kram heraus!
- User kommt "auf die Seite". Dort findet er Links zu Herstellern
- User klickt auf einen Link, der zu einer Unterseite mit einem bestimmten Hersteller führt.
Wo hast Du hier das Bedürfnis, nur einen Teil der Seite inhaltlich zu aktualisieren? Und warum kannst Du mit PHP nicht einfach die Unterseite mit allen ihren Bestandteilen wieder zusammenstellen? Und warum sollte das weniger wünschenswert sein, als nur einen Teil mit clientseitiger Technik (JavaScript ist etwas anderes als Java!) auszutauschen?
Liebe Grüße,
Felix Riesterer.
-
Moin,
Wo hast Du hier das Bedürfnis, nur einen Teil der Seite inhaltlich zu aktualisieren? Und warum kannst Du mit PHP nicht einfach die Unterseite mit allen ihren Bestandteilen wieder zusammenstellen? Und warum sollte das weniger wünschenswert sein, als nur einen Teil mit clientseitiger Technik (JavaScript ist etwas anderes als Java!) auszutauschen?
- um Traffic zu sparen?
- Seiteninhalt schneller ausliefern zu können?
- Nicht gespeicherte User Eingaben zu verlieren?
- geile Übergänge?
Da fällt mir einiges ein.
-
@@Bernd
Wo hast Du hier das Bedürfnis, nur einen Teil der Seite inhaltlich zu aktualisieren? Und warum kannst Du mit PHP nicht einfach die Unterseite mit allen ihren Bestandteilen wieder zusammenstellen? Und warum sollte das weniger wünschenswert sein, als nur einen Teil mit clientseitiger Technik (JavaScript ist etwas anderes als Java!) auszutauschen?
- um Traffic zu sparen?
- Seiteninhalt schneller ausliefern zu können?
“Things to avoid: Assuming Ajax always delivers a faster and better user experience” —Adam Silver in Form Design Patterns
Sagte ich schon, dass dieses Buch in der Bibliothek eines Webentwicklers nicht fehlen sollte?
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
-
Hallo Felix,
einige Gründe hat ja Bernd schon genannt, warum ich nicht jedes mal die ganze Seite neu aufbauen will. Dazu kommt, wenn die Verzweigung immer tiefer geht …
Hersteller -> Artikel des Hersteller -> Eizelteile des Artikel usw.
dann werden es irgendwann unendlich viele Parameter die ich übergeben muss und beim Neuaufbau der Seite berücksichtigen muss.
Es tut mir leid wenn ich dich mit meinen Fragen etwas nerve ( hab beinahe das Gefühl :( ), aber ich wollte ja auch keine fertige Lösung für meine Seite sondern nur einen Denkanstoß, wie von den anderen in Richtung target/fetch etc. Ich bin ja bereit mich dann weiter zu belesen und es selber raus zu finden.
Es wäre halt aus meiner Sicht besser nur den Teil der Seite zu aktualisieren, welcher auch aktualisiert werden muss und hier wollte ich nur wissen ob es da Möglichkeiten gibt ( gerne ohne java/javascript ). Mein Denken geht in die Richtung ( vielleicht blödes Beispiel ) ... wenn ich den Sitzbezugs eines Auto wechseln will, baue ich das Auto ja auch nicht von Grund neu auf.
Ich hoffe auch wir reden hier nicht irgendwie aneinander vorbei!?
Grüße Lars
-
Hallo Sassl,
dann werden es irgendwann unendlich viele Parameter die ich übergeben muss und beim Neuaufbau der Seite berücksichtigen muss.
Ich habe zwei schlechte Nachrichten für Dich:
-
Das wird bei einer Ajax-Seite nicht einfacher. Die Komplexität der Business-Logik hängt eher nicht von der verwendeten Technologie ab.
-
Was machst Du mit Leuten, die JavaScript deaktiviert haben? Willst Du die von der Nutzung deiner Seite ausschließen? Ajax kann immer nur ein Progressive Enhancement sein, aber niemals die einzige Lösung. Was Du bisher genannt hast: Hersteller / Artikel / Einzelteil - das sind 3 IDs, mehr nicht, das ist noch gut zu handhaben. Dann kommt noch der Punkt des Deeplinking. Eine per Ajax aktualisierte SPA[1] sollte über Hash-URLs ihren Zustand darstellen, damit man auf eine bestimmte Ansicht einen Favoriten setzen kann (z.B. http://example.org/showData#Brumm,Mk2-2015,Hinterachse. In der Nicht-Javascript-Version kannst Du die Parameter nicht hinter den Hash stellen (weil der nicht am Server ankommt), darum sollte der Link ähnlich aussehen, z.B. so: http://example.org/showData/Brumm/Mk2-2015/Hinterachse oder so: http://example.org/showData?marke=Brumm&modell=Mk2-2015&teil=Hinterachse.
Serverseitig ist wichtig, dass Du den Code, der die Daten für diese Levels bereitstellst, gut isolierst. Für einen Ajax-Betrieb ist wichtig, dass Du bspw. den Code für die Darstellung der Informationen zu einem Hersteller eigenständig nutzen kannst, so dass Du den Herstellerdatenblock wahlweise in einem kompletten Seitenneuaufbau und in einem Ajax-Request verwenden kannst.
Trivial wird es in keinem Fall.
Rolf
--
sumpsi - posui - clusi
Single Page Application ↩︎
-
-
-