Teil1

Styleheets können groß werden

• komplex, schlecht lesbar

• schlechte wartbarkeit

• ggf. verlängerte Ladezeit wenn zugroß

wucherung

• überspezifischer Selektoren

• redudanter code

erweitern css sprachumfang

typischerweise obermenge von css

stylesheets werden von präprozessoren in reines css übersetzt

erweiterung

• Variablen

• Mixings

  • Wiederverwenden ganzer Blöcke aus CSS Deklarationen

• Imports

  • ziel: Modularisierung stylesheet

  • Präprozessor erzeug aus allen Stylesheets eine Datei

  • nicht verwendete Elemente landen nicht im erzeugten CSS

• Verschachtelte Regeln

  • Ziel: Lesbarkeit erhöhen

  • Aufgbau spiegelt HTML-Struktut wieder

  • Gefahr: zu starke Verschachtlung führt zu starke kopplung an HTML

scss

• echte obermenge von css

• leicht in komib mit bestehenden CSS nutzbar

Indented Syntax

• abgeleitet von yaml

• mit einrückung statt semikolons

konventionen und regeln für arbeit mit css

• namenskonventionen

• regeln, wann welche Selektoren einzusetzen sind

• Muster zur Strukturierung von CSS-Regeln

Oft werkzeuge fürs einhalten von Regeln zb Linter

Block element modifier

namenskonvention für css

ausschließlich mit CSS Klassen, keine IDs

• grund: zu enge komplllung zwischen Struktur und Darstellung vermeiden

• Spezifität zu gunst der erweiterbarkeit niedrig halten

  
  

Blöcke

• logisch und funktion eigenständige wiederverwendbare Einheit einer Webseite

• können ineiander verschatelt werden

• zb. Menü-block, login-block

Elemente

• bestandteile von blöcke

• sind semantisch an ihren block gebunden, können alleine nicht existieren

• zb Menü-element im Menü-block

Modifizierer

• einstellung von blöcken

• zb verhalten oder aussehen eines Blocks oder Elements anzupasen

• zB menüblock hervorheben

Pro

• können zu warbarerem, skalierbarerem CSS führen

• in der regel werkzeuge für unterstützung der durchführung

Contra

• muss erlernt, verstanden und beherrscht werden

• ohne werkzeugunterstütztung viel disziplin auf seiten enwickler

Framework ruft funktionen des Programmes auf

Kontrolle wird dem Framework übergeben

verschiedene Wege zu realisierung

Dependency Injection

• Framework oder Container übernimmt Instantiierung und Verwaltung der Abhängigkeiten zB. Spring

• Template Method Pattern (Schablonenmethode)

• Observer Pattern zb Model View Controller

Beans

• von Spring verwaltete Objekte

Autowiring

• Dependency Injection

• instantiierung, und Injektion abhhängiger Beans

Application Context

• IoC Container von Spring

• erstellt und verwaltet alle Beans

• Konfigurationsmetadaten beschreiben wie Applikationsklassen instantiieren, verdrahtet und konfigurieren soll

Konfigurationsmetadaten per:

• Annotation

• java

Pro

• gute lesbarkeit, Konfigurationsmetadaten und Applikationsklasse an einem Ort

• in kombi mit Spring MVC und Spring Boot einfach verndbar

Contra

• konfigurationsmetadaten nicht zentralisiert, sondern über Anwendung verteilt

• nicht anwendbar wenn Applikationsklasse nicht änderbar ist

Konfigurationsmetadaten in Klasse spezifiziert, die mit Configuration annotiert sind

• deklarieren beans über methoden mit @Bean annotation

  • Abhängigkeiten zwischen Beans werden durch Aufrufe dieser Methoden modelliert

Vorteil

• zentralisierte Konfiguration

• nicht invasiv, Applikationsklassen müssen nicht angepasst werden

• modularisierung möglich, verhindert zu große Konfigurationsklasse

Dependency Injection in Spring

Prozess

• Abhängigkeiten indentifiziert

• Matches für Abhängigkeiten indentifiziert

• abhängigen Beans instantiiert und injiziert

drei Arten:

• via Konstruktor (constructor injection) für obligatorische Abhängikeiten

• via Setter (setter injection) für optionale Abhängigkeiten

• via Klassenattribut (property/field injection)

  • nicht verwenden da ggf. unsicherem Code, Schwer Testbar da abhängige klasse nicht von außen sichtbar, verletzt prinzip der Datenkapselung

sucht annotierte Klassen und registrierte diese Automatisch als Beans im Application Context

Standard: alle mit @Component annotierte Klasse berücksichtigt

z.B. Service, Restcontroller, Repository

haben spezielle Funktionalitäten

anwendung über @SpringBootapplication starten

annotation aktiviert:

• Configuration (favorisiert Java-basiert)

• ComponentScan

• Auto-Configuration

  • inspiziert Klassenpflad und versucht sinnvole Konfig automatisch vorzunehmen (Convention over Configuration)

Architekturmustur zur Strukturierung der Präsentationsschicht

Ziele:

• Zuständigkeiten trennen

• Anpassrbarkeit und Erweiterbarkeit

• Wiederverndbarkeit, gleiche Model für andere Views und Controller

Entkoplung Model und View häufig über observer pattern, View beobachtet Model

Model unabhängig von View und Controller