Ich habe in letzter Zeit mehrfach beobachtet, wie für aktive Anwendungen am Frontend eine HTML Seite angefordert wird, wie hier im Luxx Forum z.B. . Auch für Webshops habe ich das schon gesehen.
HTML ist das einzige, was Webbrowser (Chrome, FF, ...) interpretieren können. So ziemlich jede Webseite im Internet basiert auf HTML; die Herkunft der Inhalte ist dabei irrelevant.
Bei meinen aktiven Anwendungen werden meist direkt die PHP oder ASP Scripts aus dem Browser aufgerufen.
Es wird lediglich gesendet und empfangen.
Vereinfacht gesagt verläuft das so:
- du sendest einen Request an einen Server (z.B. "hardwareluxx.de/index.php")
- am Server "lauscht" ein Dienst (z.B. Apache, NodeJS, etc.) auf einen bestimmten Port. I.d.R. laufen die meisten Anwendungen über Port 80, wodurch die genannte URL eigentlich "hardwareluxx.de:80/index.php" ist, das wird jedoch automatisch vom Browser mitgeschickt
- dieser Dienst weiß, was er mit dem Request anfangen soll und jagt die angeforderte Datei, in diesem Fall die "index.php", durch einen PHP Interpreter
- der Interpreter liefert eine Antwort aus dem Script
- diese Antwort (Response) wird vom Server an den Client der den Request gesendet hat zurückgeliefert und dargestellt
Ein Response kann natürlich nicht nur HTML sein; es kann z.B. auch eine PDF-Datei, JSON, ein einfacher Response Code (z.B. 404) sein, eine ZIP-Datei oder was auch immer. Im Endeffekt aber greift dein Browser
niemals direkt auf eine PHP (oder ASP, JS, ...) Datei zu - er wüsste nicht was er damit anfangen soll. Er schickt lediglich Anfragen an einen Server der dann entsprechende Antworten schickt. Bildlich gesprochen würde das so aussehen:
https://upload.wikimedia.org/wikipedia/commons/5/51/PHP_funktionsweise.png
Bei einem PHP Statistik Skript hatte ich sowas Mal: da konnte man in einer PHP Anwendung in einer HTML Seite das Design der Ausgabe anpassen. Die HTML Seite wurde dann schlussendlich auch über das aufgerufene PHP Script mit eingebunden.
Im Regelfall werden heutzutage Template Systeme (
https://de.wikipedia.org/wiki/Template-Engine) für die Ausgabe verwendet. Zwar kann man HTML direkt in PHP-Dateien packen, was aber im Endeffekt ziemlicher Nonsense ist (schlechte Wartbarkeit, unübersichtlich, etc.).
Aber wie realisiert man das aber bei in einem Forum, bzw. einem Webshop?
Meist werden hierfür relativ komplexe Frameworks eingesetzt, die u.A. auch über eine Template Engine verfügen. Über bestimmte Design Patterns (allem voran MVC) bleibt die Software konsistent und wartbar.
Um Inhalte dynamisch zu laden werden JS-Frameworks (wie Ember, Angular, etc.) verwendet. Dabei werden sogenannte AJAX-Requests an den Server geschickt (die funktionieren genau so wie oben genannt, liefern jedoch dann meist nur JSON oder so zurück). Das JS-Framework kümmert sich dann um die Modifizierung des DOMs und die Einbindung der frisch geladenenen Elemente.
Z.B. bei einem Webshop, gibt es da die Möglichkeit, für jedes Produkt dann auch eine eigene Seite abzulegen? Oder wird das HTML Gerüst wirklich nur zur Ausgabe verwendet, und der Inhalt liegt nach wie vor nur in einer Datenbank?
Ein AJAX Request in jQuery kann zB wie folgt aussehen:
Code:
$.ajax({
url: "/products/all",
method: "GET",
}).done(function(data) {
/* do something with data */
});
Damit würde man, sofern der Server bei einem Request auf "products/all" entsprechend antworten, alle Produkte erhalten. Die data-Variable der done-Methode enthält dann was man vom Server zurückbekommt; ob das nun HTML, JSON, wasauchimmer ist, ist egal. Man muss es nur entsprechend handeln um einen gewünschten Effekt zu erzielen.
Anmerkung: es ist absolut KEINE gute Idee in einer komplexeren Anwendungen jQuery für AJAX Requests zu verwenden. jQuery ist zur Modifizierung des DOMs, nicht für das Verwalten von Inhalten. Wie schon gesagt gibts dafür Frameworks wie Angular, Backbone, Ember, etc..
Cool wär halt z.B. ein Shop, wo die Produkte in HTML vorlägen, und der Warenkorb und solche Sachen dann natürlich auf dem Server laufen. So stelle ich mir das bislang vor, nur habe ich noch keine Erfahrungen machen können damit.
Prinzipiell keine gute Idee. Im Normalfall werden Daten vom Server als JSON bereitgestellt und dann, wie schon erwähnt, von einem JS-Framework eingebunden. HTML vom Server dynamisch nachzuladen hat Wartbarkeitsnachteile und kann daher zu Problemen führen.
Ein Beispiel dazu:
Man hat eine einfache Liste und will alle Inhalte dieser Liste dynamisch laden.
Das HTML dieser Liste sieht wie folgt aus
Über JS werden dann die Inhalte dynamisch geladen
Code:
$(function() {
$.ajax({
url: '/products/all',
method: 'GET'
}).done(function(products) {
$.each(products, function(product) {
$('#products').append('<li>' + product.name + '</li>');
});
});
});
Und unser Server müsste beim Aufruf von "products/all" wie folgt aussehen (in PHP):
Code:
<?php
$products = [
[
"name" => "Produkt 1"
],
[
"name" => "Produkt 2"
],
[
"name" => "Produkt 3";
]
];
header('Content-Type: application/json');
echo json_encode($products);
Damit wäre unser Response vom Server JSON und unsere Liste würde im Endeffekt 3 Produkte beinhalten. Man sollte beachten, dass es sich hierbei nur um ein Beispiel handelt was ich schnell aus dem Kopf gebastelt habe; bitte nicht glauben, real sieht das 1:1 so aus (es fehlt die Nutzung von Frameworks, wie gesagt ist jQuery nicht wirklich gut für sowas, etc.) - aber für ein Beispiel reicht es.
Natürlich könnte der Response vom Server direkt auch so aussehen:
Code:
echo '<li>Produkt 1</li><li>Produkt 2</li><li>Produkt 3</li>';
Das JS müsste dann etwas modifiziert werden:
Code:
$(function() {
$.ajax({
url: '/products/all',
method: 'GET'
}).done(function(products) {
$('#products').append(products);
});
});
Wie aber schon gesagt bindet man sich damit daran, dass der Server immer das richtige HTML liefert. Will man nun z.B. den <li>-Elementen der Produkte eine Klasse mitgeben muss man das dem Server sagen - und das ist weder gut noch schön gelöst.
Schau dir mal den Quelltext dieser Seite etwas genauer an. Es wird nicht wirklich eine echte HTML Seite angefordert.
Doch. Unechtes HTML existiert nicht (zumindest nicht in den Browsern die ich so kenne und nutze
)
Du bekommst vom Server eine fast leere HTML Seite mit diversen Java Scripten (AJAX) ausgeliefert.
Das stimmt so, aber die Antworten in Threads werden hier nicht über AJAX geladen sondern direkt mitgeliefert. Man findet alle Beiträge dieses Threads im für den Client ersichtlichen Code.
Für SEO ist es völlig unerheblich ob du richtige HTML Seiten hast oder ob die Seiten vom Server generiert werden.
Nicht ganz; das Problem ist, dass Google und Co. dynamische Inhalte schlichtweg nicht sehen. Um das zu ändern muss man diverse Vorkehrungen treffen; siehe z.B.
SEO Strategies for JavaScript-Heavy Single Page Applications or AJAX Sites | SEW,
https://developers.google.com/webmasters/ajax-crawling/docs/learn-more oder
https://support.google.com/webmasters/answer/174992?hl=de.
aber naja, du kannst unter Windows und unter Linux relative gleiche Verhältnisse schaffen. Gibt Vor- und Nachteile bei beiden.
