HTML5: Back to the future! - JAXenter
FacesTales

HTML5: Back to the future!

Lars Röwekamp und Matthias Weßendorf

Das Web ist schnelllebig! Fast jeden Tag entsteht ein neues Framework für die diversen (und auch teilweise exotischen) Sprachen zur Webprogrammierung. Schaut man auf den HTML-Standard, entsteht jedoch ein etwas anderer Eindruck. Vorbei sind die Zeiten, in denen binnen weniger Jahre eine versionslose Spezifikation rasch zur Version 4.0.1 aufstieg. Diese immer noch aktuelle Version von HTML stammt aus dem Jahr 1999 und ist auch nach fast elf Jahren nach wie vor das Maß der Dinge.

Von wissenschaftlichen Dokumenten…

Blickt man einmal ein paar Jahre bzw. Jahrzehnte zurück, so wird deutlich: Das WWW in seinen Ursprüngen ist eine Informations- und keine Applikationsplattform. Das Web der Neuzeit – a. k. a. Web 2.0 – dagegen besteht überwiegend aus Anwendungen, z. B. Social Communities, Onlinefotoalben oder Onlinebanking. Auch innerhalb von Unternehmen sieht es nicht anders aus. Hier werden ebenfalls Inter- und Intranet-Anwendungen mithilfe des HTML-Standards erstellt.

Dass die Kluft zwischen HTML/HTTP und der von Desktopanwendungen gewohnten Usability groß ist, ist nicht neu. Im Jahr 2008 wurde daher von der WHAT (Web Hypertext Application Technology Working Group, [1]) ein Vorschlag eingereicht, um auf Basis bestehender Bordmittel (z. B. HTML) eine mehr anwendungsspezifische Technologie zu schaffen. Das Hauptaugenmerk der WHAT liegt dabei, in Kooperation mit der W3C HTML Working Group, auf der Spezifikation von HTML5. Neben den ursprünglichen Zielen, wie die Bereitstellung von weiteren Komponenten (oder Widgets), enthält HTML5 komplexe Technologien, wie die Offlinespeicherung von Daten à la Google Gears oder auch WebSockets, einer standardisierten Variante für Server-Side-Push.

…zu Webanwendungen

Die Widgets von HTML 4.0.1 sind einfach gehalten. Daher ist häufig zusätzlicher Code notwendig, um den Projektanforderungen zu genügen. Als Beispiel schauen wir uns die immer wieder benötigte Funktionalität einer Datumseingabe an: Sie ist ein fester Bestandteil fast jeder Webanwendung. Heutzutage wird diese Anforderung i. d. R. selbst programmiert oder mithilfe einer (Open-Source-)Komponente realisiert. Allerdings steht man selbst bei der Verwendung einer existierenden Lösung vor einem kleinen Usability-Problem: Es gibt kein einheitliches bzw. spezifiziertes Verhalten für die Eingabe eines Datums. In einigen Projekten genügt ein einfaches Eingabefeld mit den notwendigen Validierungsregeln. Andere Projekte dagegen benötigen eine schöne „Date Picker“-Komponente. Es ist ebenfalls nicht unüblich, dass beide Varianten innerhalb einer Webanwendung auftreten, wie die Onlineportale der Deutschen Bundesbahn und Lufthansa zeigen.

Wie bereits erwähnt, stehen mit HTML5 vornehmlich anwendungszentrierte Erweiterungen innerhalb von HTML an. Daher ist es nicht verwunderlich, dass die häufig geforderte Funktionalität einer „geregelten“ Datumseingabe unterstützt wird:

<input type=„date“ min=„2010-01-01“ max=„2010-12-31“ … />

Das Eingabefeld mit dem Typ date (Abb. 1) besitzt zwei Eigenschaften, um das gewählte Datum einzuschränken. Die manuelle Eingabe des Datums ist nicht mehr möglich; der Benutzer muss den vom Browser bereitgestellten Kalender nutzen. Zusätzliche Restriktionen können über ein Attribut steps festgelegt werden. So könnte man beispielweise einstellen, dass nur jeder fünfte Tag auswählbar ist (steps=“5″).

Abb. 1: Eingabefeld mit dem Typ date

Natürlich besteht HTML5 nicht nur aus neuen Widgets und neuer Funktionalität, z. B. einer nativen Drag-and-Drop-API. Auch die bestehenden Widgets wurden zum Teil überarbeitet: So kann bei HTML5 der gewünschte MIME-Type direkt innerhalb der HTML-Seite bei Uploads bestimmt oder aber gewöhnliche Eingabefelder (<input type=“text“ />) mit dem Attribute required als Pflichtfeld markiert werden.

JSF und HTML…

Soweit so gut. Aber was hat das Ganze mit der JSF-Kolumne zu tun? JSF und HTML haben mehr gemeinsam, als man meinen könnte. Beide Standards sind von Haus aus schmal gehalten. Innerhalb des JSF-Ökosystems gibt es zahlreiche Komponentenbibliotheken, die komplexe Widgets anbieten, z. B. ein <inputDate> oder eine Baumstruktur. Das Gleiche trifft auf HTML zu: Moderne Bibliotheken wie jQuery erstellen interessante Komponenten auf Basis von HTML und JavaScript.

Die JavaServer-Faces-Spezifikation selbst hatte nie das Ziel, eine Unzahl an Komponenten zu spezifizieren. Der Fokus lag und liegt nach wie vor auf dem Framework, seiner Erweiterbarkeit sowie der Komponenten-API, um einen fluktuierenden 3rd Party Library Mark zu erzeugen. Mit Erfolg! Die aktuellen JSF-2.x-Versionen zielen dabei auf HTML 4.0.1 ab, da HTML5 noch nicht endgültig verabschiedet wurde.

Allerdings haben die verschiedenen HTML5-Widgets und Features durchaus ein hohes Integrationspotenzial, wie dieses Listing am Beispiel eines fiktiven <hx:inputDate /> Tags zeigt:

Innerhalb der <hx:inputDate/>-Komponente werden die Restriktionen für die Datumsauswahl mithilfe eines JSF Validators angegeben. Es ist gut möglich, dass kommende Versionen von JSF (3.x?) einige der neuen HTML5-Widgets berücksichtigen.

Apache MyFaces goes HTML5

Bis es allerdings soweit ist, dass HTML5 ein fester Bestandteil einer zukünftigen JSF-Version wird, müssen interessierte Nutzer auf externe Komponentenbibliotheken zurückgreifen. Das Apache-MyFaces-Projekt hat bereits erste Gehversuche mit HTML5 innerhalb des Google-Summer-of-Code-Projekts gestartet [2], [3]. Das Projekt bietet verschiedene Bestandteile von HTML5 über eigene Tags, auf Basis von JSF2, an. Neben einer „Date-Picker“-Komponente sind Prototypen für Slider-, Spinbox-, Farbauswahl- oder Video-Widgets enthalten. Das Drag-and-Drop-API von HTML5 ist auf Basis der JSF2 Behavior API implementiert. Trotz des frühen Status machen die Komponenten einen robusten Eindruck. Mittelfristig ist die Bündelung der HTML5-Funktionalität (<hx:*** />) als fester Bestandteil der Apache MyFaces-2.x-Implementierung geplant. Wenn es erst einmal soweit ist, bekommt man quasi mit der MyFaces 2.x die neuen HTML5-Features geschenkt, muss also keine Wrapper-Komponenten implementieren oder auf proprietäre 3rd Party Libraries zurückgreifen. Was wünscht man sich mehr?

Fazit und Ausblick

Klar ist, dass HTML5 noch nicht in allen Browsern funktioniert und auch hier und dort noch kleinere Schwächen hat: Das Beispiel des <input type=“date“> Widgets funktioniert derzeit nur im Opera-Browser und dessen nativer Kalender kann aktuell nicht mit CSS angepasst werden – noch nicht. Allerdings unterstreicht dieses Widget deutlich das Potenzial von HTML5. Es ist davon auszugehen, dass kleinere Probleme wie diese in naher Zukunft behoben werden.

Einen guten Überblick zum aktuellen Stand von HTML5 und dessen Umsetzung bieten [4] und [5]. Die Integration von HTML innerhalb von Webframeworks sollte problemlos verlaufen. Das Apache-MyFaces-Projekt leistet Pioniersarbeit für die Integration mit JSF. Einen sehr guten Einstieg in HTML5 bieten [6] und [7]. Wer nun starkes Interesse verspürt, aktiv an HTML5 und JSF zu arbeiten, ist herzlich eingeladen. Das Apache-MyFaces-Projekt freut sich immer über neue Contributor!

Lars Röwekamp ist Geschäftsführer der OpenKnowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).

Matthias Weßendorf arbeitet für Oracle an einer Server-Side-Push-Lösung für ADF Faces. Er ist PMC Chair von Apache MyFaces. Matthias blogt regelmäßig auf
http://matthiaswessendorf.wordpress.com
(Twitter: @mwessendorf).

Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.