Spezifikation / Library-APIUI/Core6.0

Jakarta Expression Language

Expression Language wertet Ausdrücke in serverseitigen Views und Framework-Kontexten aus.

Einordnung
Spezifikation / Library-API
Enterprise-Rolle
EL erscheint in JSP/Pages, Faces und Validierungs-/Binding-Kontexten.
Diagramm zu Jakarta Expression Language

Fachliches Verständnis

EL erscheint in JSP/Pages, Faces und Validierungs-/Binding-Kontexten. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Kernkonzepte

  • Property Access.
  • Method Expressions.
  • Resolver-Konzept.
  • Typkonvertierung.

Typische Einsatzfälle

  • Views an Backing Beans binden.
  • Formularwerte anzeigen.

Technisches Beispiel

xml
<h:outputText value="#{orderView.selectedOrder.customerName}" />
<h:commandButton value="Freigeben" action="#{orderView.approve}" />

<!-- Fachlogik gehört nicht in EL, sondern in approve() -> Application Service. -->
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.

Enterprise-Fallen

  • Komplexe Logik in EL.
  • Unsichere Ausgabe.
  • Schwer testbare View-Regeln.

Legacy-Modernisierung

EL-Ausdrücke sollten bei Migrationen inventarisiert werden, weil dort oft versteckte Fachlogik steckt.

Vertiefung: Review-Fragen für Senior-Entwickler
  • Welche Spezifikation ist hier wirklich nötig?
  • Welche Runtime-Funktion wird genutzt und ist sie portabel?
  • Wo liegt die Transaktionsgrenze?
  • Sind API-Verträge, DTOs und Domain-Modelle getrennt?
  • Ist der Code ohne Application Server testbar?
Index