Herkunft: Der fachliche Kern (Kette "Von der URL zur Seite", DNS, Client-Server, erste HTML-Folien) stammt aus Soeren Godes V1 (WiSe 25/26). Im Oktober 2026 umgebaut: Architektur-Folien (Schichten, MVC, MVP, MVVM) gestrichen, HTTP, HTML-Elemente, Formulare, Live-Demos, Quiz und Aktivphase neu. Demos: Repo swe1-demos, live unter https://swe1.mylab.th-luebeck.de/web-02/, lokal ueber marp/demos (Symlink). Praesentieren: slides/serve.sh, dann http://localhost:8000/slides/dist/web-02-www-html.html
- Erste Fachvorlesung im WEB-Strang. Gestern bei Leif: "Was ist ein Produkt?" - Nicht auf dem Titel verweilen, direkt mit der Frage einsteigen
- Zurufe sammeln und an die Tafel schreiben. Nicht bewerten, nicht korrigieren - Typisch: "Der Server schickt die Seite", "DNS", "HTTP", "Cookies", "Der Browser rendert" - Tafelbild stehen lassen. Am Ende von Station 4 vergleichen wir mit der fertigen Kette
- Fuenf Stationen: erst wie die Seite kommt (1, 2), dann wo das in Ihrem Projekt passiert (3), dann woraus sie besteht (4). Am Ende bauen Sie selbst (5) - Station 1: rund 15 Minuten
- Das Internet gibt es seit den 1970ern (ARPANET), das WWW erst seit 1989/91: Tim Berners-Lee am CERN, mit HTTP, HTML und der URL zugleich erfunden - Im Alltag sagt jede:r "Internet" und meint den Browser. Fuer uns ist der Unterschied wichtig, weil wir nur die oberste Schicht bauen: HTML, CSS, JS ueber HTTP - Ueberleitung: kurz testen, ob es sitzt
- Vorne: Frage vorlesen, Handzeichen "nur Internet" vs. "WWW". Clicker: erster Klick loest auf, zweiter holt die naechste Frage, nach der Auswertung kommt die naechste Folie - QR und Link zu den Demos stehen nur im PDF zum Nachklicken, nicht in der Live-Folie - Spannend sind DNS und das Online-Spiel. DNS braucht das Web, ist selbst aber kein Web - Nicht alle sieben Fragen machen, wenn die Zeit knapp ist: vier reichen
- Clicker steuert die Animation: jeder Klick ein Schritt, nach Schritt 9 kommt die naechste Folie - Jetzt nur den Ueberblick: alle neun Schritte in einem Zug, je ein Satz. Ca. 3 Minuten - Die naechsten Folien zoomen in die Schritte rein: DNS, Client-Server, HTTP. Bei HTML und DOM kommen wir auf Schritt 7 zurueck - Steht auch unter swe1.mylab.th-luebeck.de/web-02 zum Nachklicken
- Kurz wirken lassen, dann aufloesen: Domain Name System
- Diagramm in der Reihenfolge der Nummern durchgehen. Der Resolver macht die Arbeit, Ihr Rechner fragt nur einmal - Root weiss nur, wer .de kennt. Der .de-Server weiss nur, wer th-luebeck.de kennt. Erst der zustaendige Server kennt die Adresse - Wenn "das Internet kaputt" ist, ist es erstaunlich oft DNS
- Live im Terminal zeigen, die Zahl ist bei allen im Hoersaal dieselbe, der Resolver nicht - Server-Zeile: Das ist der Resolver, meist der Router oder der Provider. Im Eduroam ein anderer - Wer mag: nslookup google.com liefert mehrere Adressen, grosse Seiten verteilen sich auf viele Server
- Im Web ist der Client fast immer der Browser. Ein Server bedient viele Clients gleichzeitig - "Nie von selbst": Fuer Chats und Live-Updates gibt es Erweiterungen wie WebSockets, die brauchen wir im Semester nicht - In Ihrem Projekt ist Spring Boot der Server. Dazu gleich in Station 3
- Station 2: rund 20 Minuten, davon gut die Haelfte live im Browser
- Beide Nachrichten haben denselben Aufbau: Startzeile, Header, Leerzeile, Body - Der Request hat keinen Body, ein GET braucht keinen - Content-Type sagt dem Browser, was er bekommt: HTML, CSS, JSON, ein Bild - Heute ist fast alles HTTPS, also verschluesselt. Der Inhalt ist derselbe, nur unterwegs unlesbar - Alle Header und Methoden im Detail: "REST und Web-APIs" am 02.12.
- 304 sehen Sie gleich im Network-Tab oft: Der Browser hat die Datei schon, der Server sagt "unveraendert" - Bei 500 steht der eigentliche Fehler im Server-Log, nicht im Browser. Im Projekt: in der Konsole von Spring Boot - 1xx gibt es auch, spielt fuer uns keine Rolle
- Vier Finger hoch: 2, 3, 4 oder 5. Dann aufloesen - Bei der NullPointerException und der Datenbank lohnt die Nachfrage: Wer ist schuld? - 401 nur erwaehnen, 401 vs. 403 kommt bei REST
- Faustregel: Alles, was nur liest, ist GET. Alles, was etwas veraendert, nicht - Passwoerter nie per GET: Sie stuenden im Verlauf und in Server-Logs - PUT, PATCH und DELETE kommen bei REST dazu. HTML-Formulare kennen nur GET und POST
- Schnell durch, Handzeichen links/rechts. Die Anmeldung mit Passwort ist die eine, bei der es knirscht
- Das Labor schickt echte Requests an den Demo-Server und bekommt echte Statuscodes: 200, 201, 301, 404, 500 - Clicker schickt die Requests der Reihe nach, von oben nach unten. Laeuft lokal (serve.sh spielt den Demo-Server) - Besser als im iframe: auf dem eigenen Laptop oeffnen, F12, Network. Dann sehen Sie jeden Klick als Zeile - "Umgezogen" erzeugt zwei Requests: erst 301, dann folgt der Browser von selbst - Ueberleitung: Das machen wir jetzt mit einer echten Seite
- Studierende machen auf dem eigenen Laptop mit: Die Demo ist das Frontend der Projektvorlage, der Server antwortet auf GET und POST echt, speichert aber nichts (eigene Eintraege merkt sich der Browser) - Vorne am besten dieselbe URL zeigen (offline: localhost:8000/demos/web-02/gaestebuch/). DevTools-Schrift hochgedreht (Settings → Appearance → Font size), "Disable cache" an - Gaestebuch, 4 Min: Request auf / anklicken, Headers (Methode, Status, Content-Type), dann Response (das HTML). api/entries: application/json, Tab Preview. Eintrag absenden: POST, Payload ansehen, danach direkt das GET hinterher - th-luebeck.de, 4 Min: Erst raten lassen, wie viele Requests. Dann neu laden, Zahl unten ablesen. Wasserfall: erst das HTML, dann alles, was darin verlinkt ist. Filter Doc, CSS, JS, Img - Disable cache aus, neu laden: ploetzlich 304 und "(memory cache)" - th-luebeck.de laesst sich nicht in eine Folie einbetten (X-Frame-Options), deshalb echter Tab
- 5 Minuten, eine Folie
- Genau das haben Sie eben im Network-Tab gesehen: erst die Dateien, dann api/entries - In der Vorlage: app/src/main/resources/static/ ist das Front-End, src/main/java das Back-End - Die Seite wird im Browser zusammengesetzt, nicht auf dem Server. Den anderen Weg gibt es auch: Der Server baut das HTML pro Anfrage fertig (z. B. Thymeleaf). Den gehen wir bewusst nicht, damit Front-End und Back-End sauber getrennt sind und Sie beide Seiten kennenlernen - Reihenfolge im Semester: HTML, CSS, JS zuerst (Browser), REST und Spring Boot ab KW 49 (Server)
- Station 4: rund 30 Minuten. Zurueck zu Schritt 6 der Reise: Der Server hat ein HTML-Dokument geschickt. Was steht da drin?
- Erst fragen, dann aufdecken: "Warum eigentlich nicht?" - Der Screenreader ist das staerkste Argument: Ein Bild kann man nicht vorlesen
- WHATWG: der Zusammenschluss der Browserhersteller (Apple, Google, Mozilla, Microsoft). Das W3C hat 2019 die Pflege von HTML offiziell an die WHATWG abgegeben - "HTML5" ist heute nur noch ein Schlagwort - MDN statt w3schools: genauer und naeher am Standard
- Clicker deckt Zeile fuer Zeile auf, was sie tut. Vorher kurz fragen: Was kennen Sie schon? - So beginnt die index.html in Ihrer Projektvorlage, fast Zeile fuer Zeile - doctype: "modernes HTML", sonst schaltet der Browser in einen Kompatibilitaetsmodus - head: Infos ueber die Seite, nicht sichtbar. body: alles Sichtbare - lang="de": Screenreader lesen deutsch vor, der Browser bietet keine Uebersetzung an - charset utf-8: sonst werden Umlaute zu Zeichensalat - viewport: ohne diese Zeile sieht die Seite auf dem Handy winzig aus - link und script: genau die Dateien, die wir eben im Network-Tab nachladen sahen
- Falsch: <b><i>Text</b></i>. Richtig: <b><i>Text</i></b>. Kommt gleich in der Fehlersuche - Attribute, die Sie ab jetzt staendig sehen: id und class (fuer CSS und JS), href, src, alt - Gross- und Kleinschreibung ist egal, Konvention ist klein
- Weitere: link, hr, source. Die Liste ist kurz und aendert sich nicht - Der Browser verzeiht fast alles. Das heisst nicht, dass es richtig ist. Pruefen: validator.w3.org/nu
- Die HTML-Werkstatt: links tippen, Mitte Browser, rechts der DOM-Baum. Hover im Baum markiert das Element - Vorfuehren, je eine Aenderung live: - h2 zu h3 machen: Es sieht nur kleiner aus, die Gliederung aendert sich - strong: heisst "wichtig", nicht "fett". Dass es fett aussieht, ist nur die Voreinstellung - Link anklicken: Die Werkstatt bleibt stehen und sagt, wohin er fuehrt - alt beim Bild aendern, src kaputt machen: Dann sieht man nur noch den alt-Text - Grau im Baum: html, head und body hat der Browser selbst ergaenzt, weil sie im Text fehlen - Clicker: weiter zu Listen und Tabellen (ohne Baum, die Tabelle braucht Platz), danach naechste Folie - ul zu ol aendern: ploetzlich nummeriert. ol, wenn die Reihenfolge zaehlt (Schritt 1, 2, 3) - Navigationsmenues sind fast immer eine ul mit Links - Tabellen nur fuer Tabellendaten, nie fuer Layout. Layout macht CSS - Bei groesseren Tabellen kommen thead und tbody dazu, siehe MDN
- nav: Hauptnavigation. main: genau einmal pro Seite - section: thematischer Abschnitt mit Ueberschrift. article: abgeschlossener Inhalt, der fuer sich stehen kann (ein Eintrag, eine Fahrt) - Code-Qualitaet wird im Projekt mitbewertet, dazu gehoert sauberes HTML - Den Code dazu gibt es in der Werkstatt unter "Semantische Struktur"
- label: Klick aufs Label setzt den Fokus, Screenreader lesen die Beschriftung vor. Ein placeholder ersetzt kein label - Ohne name wird das Feld nicht gesendet, ohne Fehlermeldung. Zeigen wir gleich - Weitere Typen: email, password, checkbox, radio. Dazu select fuer Auswahllisten, textarea fuer Text - Die Browser-Pruefung ist Komfort. Der Server muss trotzdem pruefen, denn den Browser kann jede:r umgehen
- Formular-Roentgen: links das Formular, rechts der Request, der beim Absenden rausginge. Live beim Tippen - Der Clicker geht genau diese Reihenfolge durch, danach naechste Folie - Reihenfolge: method="get" (alles in der URL), dann method="post" (alles im Body). Die Farben verbinden Feld und Wert - "Datum ohne name" anhaken: Das Feld verschwindet einfach aus dem Request. Klassiker im Projekt - Zum Schluss "fetch + JSON": So macht es Ihr Projekt. JavaScript faengt das Absenden ab und schickt JSON, die Seite bleibt stehen. Genau das war der POST api/entries im Gaestebuch - Details zu fetch in JavaScript Teil 2 und bei REST
- Erst nur den Code zeigen (Werkstatt laeuft, aber noch nicht Pruefen klicken). Zu zweit sammeln lassen - Acht Fehler stecken drin: doctype, lang, charset, h1 auf h3, b und i ueber Kreuz, img ohne alt, input ohne label, input ohne name - Dann mit dem Clicker aufdecken: jeder Klick ein Fehler, die Zeile wird markiert. Nach dem achten geht es zur naechsten Folie - Spannend: Die Seite sieht trotzdem "richtig" aus. Im DOM-Baum sieht man, dass der Browser das b/i-Kreuz still repariert hat. Verlassen Sie sich nicht darauf
- Live: Elements-Tab im Gaestebuch, ul aufklappen, Eintraege zeigen. Dann den Quelltext (Strg+U) daneben: Dort ist die ul leer! Die li hat app.js erst nachtraeglich in den Baum gehaengt - Im Elements-Tab einen Text per Doppelklick aendern: Die Seite aendert sich sofort, beim Neuladen ist alles wieder weg. Sie haben den Baum geaendert, nicht die Datei - window ist das globale Objekt des Browserfensters und kennt das document, ist aber selbst kein Knoten - Mehr zum DOM in JavaScript Teil 2 (28.10.)
- Startet wieder bei Schritt 1: mit dem Clicker zuegig durch, bei 6 und 7 (Parsen, Nachladen) verweilen, die sind jetzt verstaendlich - Jetzt mit dem Tafelbild vom Anfang vergleichen: Was hatten wir, was fehlte, was war anders? - Jeder Kasten "Nachladen" ist ein eigener HTTP-Request, siehe Network-Tab
- Rund 15 Minuten: Aktivphase, dann Ausblick
- Werkstatt per QR oder Link im Lernraum. Wer lieber lokal arbeitet: Editor plus Browser, Datei per Doppelklick oeffnen - Ohne Laptop: den DOM-Baum der eigenen Startseite auf Papier zeichnen - Rumgehen. Typische Fehler: label ohne for, Feld ohne name, h1 fuer Schriftgroesse - Nach 12 Minuten zwei, drei Ergebnisse am Beamer zeigen lassen (Freiwillige) - Nebeneffekt gewollt: Wer noch keine Idee fuer P1 hat, denkt jetzt darueber nach - Wenn die Zeit knapp ist: auf 8 Minuten kuerzen, Punkt 3 streichen
- Kurz zusammenfassen, nicht nochmal erklaeren - Wenn jemand nur eine Sache mitnimmt: DevTools oeffnen, wann immer etwas nicht geht
- P1 ist unbewertet, aber Pflicht. Ohne P1 geht es mit P2 nicht weiter - Abgabe heisst Tag pushen, danach in GitLab unter Tags pruefen - Folien und alle Demos: Lernraum unter Vorlesung Web-Engineering, Demos auch unter swe1.mylab.th-luebeck.de/web-02 - Gleich im Anschluss: Praktikum