Teil 1: HTML5-Tags und WebSockets

Neuheiten in ASP.NET Web Forms 4.5
Kommentare

Nachdem Microsoft in den letzten Jahren ASP.NET MVC sehr rasant ausgebaut hatte, sprachen viele „Experten“ schon vom Ende von ASP.NET Web Forms. Die Neuerungen in ASP.NET Web Forms, Version 4.5 zeigen aber, dass auch dieses Modell nicht nur lebt, sondern auch noch weiterwächst.

Die Bedeutung von ASP.NET Web Forms sollte man nicht unterschätzen. Die Statistiken der Website builtwith.com weisen für ASP.NET einen Marktanteil von 20 bis 25 Prozent − je nach Betrachtungsmenge − aus (Abb. 1). ASP.NET MVC hingegen rangiert lediglich zwischen 0,5 und 1,4 Prozent (Abb. 2). Auch wenn unklar bleibt, ob ASP.NET MVC in der Statistik „ASP.NET“ enthalten ist, wird doch so oder so klar: Der Marktanteil von ASP.NET MVC bleibt weiterhin gering im Vergleich zu ASP.NET Web Forms. Und Abbildung 3 und 4 zeigen, dass ASP.NET nach PHP die zweitwichtigste Webentwicklungsplattform auf der Welt ist. Microsoft wird sich von so einem erfolgreichen Produkt doch nicht verabschieden wollen! ASP.NET war immer ein Aushängeschild der Microsoft-.NET-Plattform und ist nach Meinung des Autors auch weiterhin hinsichtlich der Produktivität den Java-Pendants (JSP, Servlets, JSF) überlegen. Dementsprechend hat die Java-Plattform auch nur Marktanteile von 2,5 Prozent unter den „Top Million Websites“. Bei den „Top 10 000 Websites“ ist der Anteil mit 8,2 Prozent natürlich höher. Nach dieser Motivation nun also ein Blick auf ASP.NET Web Forms 4.5.

Abb. 1: Verbreitungstrend für ASP.NET. Quelle: http://trends.builtwith.com/framework

Abb. 2: Verbreitungstrend für ASP.NET MVC. Quelle: http://trends.builtwith.com/framework

Abb. 3: Webframeworks in der breiten Masse der Websites. Quelle: http://trends.builtwith.com/framework

Abb. 4: Webframeworks unter den Top 10 000 Websites weltweit. Quelle: http://trends.builtwith.com/framework

Installation

ASP.NET 4.5 ist (wie bisher) auch Teil von .NET Framework 4.5. Ein Client Profile ohne ASP.NET, das es in .NET 3.5 SP1 und .NET 4.0 gab, gibt es in .NET 4.5 nicht mehr – so gesehen besteht keine Gefahr, das falsche .NET Framework zu installieren. In Windows 8 und Windows Server 2012 ist ASP.NET 4.5 schon im Standard installiert. Für andere Betriebssysteme gilt für die korrekte Installation von ASP.NET im Internet Information Server (IIS) wie bisher:

  • Im einfachsten Fall installiert man erst IIS-Webserver, dann .NET Framework 4.5. In diesem Fall wird ASP.NET korrekt im IIS eingetragen.
  • Wenn man den IIS nachträglich auf einem System mit .NET Framework 4.5 installiert, dann muss man die Verbindung zwischen IIS und ASP.NET 4.5 durch das Ausführen von aspnet_regiis.exe manuell herstellen.

Aufgrund der Tatsache, dass das .NET Framework 4.5 sich als ein „In-Place-Update“ von .NET 4.0 versteht und in den ersten drei Versionsnummern nicht von .NET 4.0 unterscheidet – in Verbindung mit der Tatsache, dass der IIS an den relevanten Stellen nur die ersten beiden oder ersten drei Versionsnummernteile anzeigt −, kann man im IIS selbst nicht erkennen, ob ASP.NET 4.0 oder 4.5 installiert ist. So ist das Vorhandensein der Auswahl „.NET Framework 4.0.30319“ für einen Application Pool (Abb. 5) oder das Vorhandensein von ASP.NET-ISAPI-Filter in Version 4.0.30319 (Abb. 6) ein Indiz dafür, dass ASP.NET 4.0 oder ASP.NET 4.5 installiert und korrekt mit dem IIS verbunden ist. Um welche Version es sich genau handelt, kann man hier aber nicht sehen. Es kommt darauf an, was auf dem System installiert ist. Die Version erkennt sie nur an der vierten Stelle der Versionsnummer. .NET 4.0 hatte die Versionsnummer 4.0.30319.269, und .NET kommt nun unter die Nummer 4.0.30319.17929 daher. Diese Versionsnummer liefern alle .NET-DLLs und alle .NET-Werkzeuge (z.B. csc.exe) sowie die Eigenschaft Version der statischen Klasse System.Environment.

Abb. 5: Auswahl des .NET Frameworks in den „Basic Settings“ eines Anwendungspools. Die 4.5-Application Pools verwenden als .NET-Framework-Version dann auch „4.0.30319“

Abb. 6: Installierte ISAPI-Filter sind ein Indiz dafür, dass ASP.NET 4.0 oder 4.5 korrekt mit dem IIS verbunden wurden. Genauer ist dies hier aber in der MMC leider nicht feststellbar

Neue HTML-Serversteuerelemente für HTML5

Es gibt aber keine neuen echten ASP.NET-Webserver-Steuerelemente in ASP.NET Web Forms 4.5. Microsoft hat in Hinblick auf HTML5 ein paar Verbesserungen in bestehenden ASP.NET-Webserver-Steuerelementen ausgeführt sowie neue HTML-Server-Steuerelemente für neue HTML5-Elemente eingeführt. Zur Erinnerung: HTML-Server-Steuerelemente sind eine ganz einfache Form von Serversteuerelementen, die einige Funktionen des Web-Forms-Programmiermodells (z. B. AutoPostBack, automatische Anpassung an Browser, Designthemen) nicht unterstützen. Ein HTML-Server-Steuerelement ist eine 1:1-Abbildung eines HTML5-Tags in ASP.NET, während ein ASP.NET-Webserver-Steuerelement eine Vielzahl von HTML5-Tags erzeugen kann.

Zu den neuen HTML-Server-Steuerelementen gehören u.a.

,
,
. Dazu versieht man diese neuen HTML5-Tags – wie bisher auch die alten HTML-Tags – mit dem Zusatz runat=“server“ (Listing 1). Dann kann man diese HTML5-Tags im Servercode ansprechen (auslesen und manipulieren, siehe Listing 2).

Listing 1: HTML5-Steuerelemente als ASP.NET-HTML-Server-Steuerelemente
Listing 2: Verändern der HTML5-Steuerelemente auf dem Server
     this.C_Header.InnerText = "Neuheiten in ASP.NET 4.5";      this.C_Header.Attributes["style"] = "font-size:x-large;";       this.C_Inhalt.InnerText = "Es gibt zahlreiche Neuheiten. Dies sind: ...";       this.C_Footer.Attributes["style"] = "font-size:small;";       this.C_Footer.InnerText = "Autor: Dr. Holger Schwichtenberg";      this.C_Summary.InnerText = "Ein Beitrag über die Neuheiten in ASP.NET 4.5";
Verbesserung in den ASP.NET-Webserver-Steuerelementen

Microsoft hat kleinere Erweiterungen bestehender Webserver-Steuerelemente in Hinblick auf HTML5 durchgeführt. Das TextBox-Steuerelement bot bisher in der Eigenschaft TextMode die Auswahl „SingeLine“, „MultiLine“ und „Password“. Nun sind folgende Optionen hinzugekommen: Color, Date, DateTime, DateTimeLocal, Email, Month, Number, Range, Search, Phone, Time, Url und Week (Listing 3). Folgerichtig werden -Tags mit dem entsprechenden Attribut „type“ erzeugt (Listing 4). Das FileUpload-Steuerelement besitzt jetzt für HTML5 eine neue Eigenschaft AllowMultiple. Wenn man sie auf „true“ setzt, wird das -Tag wie folgt gerendert: . Browser erlauben dann beim Upload die Auswahl mehrerer Dateien.

Am Beispiel dieser neuen Möglichkeiten der Eingabefelder kann man sehr gut sehen, wie unterschiedlich und tendenziell noch schlecht die HTML5-Unterstützung zum Zeitpunkt der Erstellung dieses Beitrags in aktuellen Browsern ist. In Abbildung 7 sieht man die Darstellung des Beispiels aus Listing 3 und 4 in Opera 12.00, Internet Explorer 9, Firefox 13.0.1 und Chrome 19.0. Man sieht: Opera bietet aktuell die beste Unterstützung für diese HTML5-Tags.

Listing 3: Einsatz der neuen TextMode-Optionen im ASPX-Quelltext
Email:    Date:     Week:     Month:    Time:     Range:    URL:      Color:   
Listing 4: Die aus Listing 3 erzeugten HTML-Tags aus Sicht des Browsers
Email:   Date:    Week:    Month:   Time:    Range:   URL:     Color:  

Abb. 7: Die neuen Eingabefeldtypen in verschiedenen aktuellen Browsern

[ header = Neuheiten in ASP.NET Web Forms 4.5 – Teil 2 ]

WebSockets mit ASP.NET 4.5

WebSockets ist ein relativ junger, neuer W3C-Standard (RFC 6455 vom Dezember 2011) für bidirektionale Kommunikation zwischen Webbrowser und Webserver. Bisher war die HTTP-Kommunikation zwischen Webbrowser und Webserver auf das Anfrage-Antwort-Modell beschränkt: Der Browser stellt eine Anfrage, und der Webserver kann eine Antwort senden. Der Webserver kann aber nicht selbst aktiv an den Browser Daten senden. Der Browser kann lediglich durch wiederholtes Anfragen (Polling) beim Server nachfragen, ob es neue Daten gibt. WebSockets basieren auf HTTP. Nachdem der Browser erstmals die Kommunikation per HTTP eingeleitet hat, bleibt die darunterliegende TCP-Verbindung offen. Man nennt dies ein „Upgrade“, das der Webbrowser im HTTP-Header der Anfrage explizit anfordern muss (Upgrade: WebSocket). Der Webserver bestätigt dies in der HTTP-Antwort (siehe Abb. 8). WebSockets-Kommunikation wird über Port 80 und 443 (SSL) abgewickelt, als Prefixe kommen ws: und wss: (SSL) zum Einsatz. Clientseitig muss mit JavaScript die Interaktion eingeleitet sowie die Nachrichten des Webservers behandelt werden. Dafür benötigt man das Objekt WebSocket mit den Operationen OnOpen(), OnMessage(), OnClose(). Voraussetzung ist ein Browser, der WebSockets unterstützt. Das sind aktuell:

  • Internet Explorer seit Version 10
  • Firefox seit Version 7
  • Chrome seit Version 4
  • Opera seit Version 1

Aber auch serverseitig müssen WebSockets explizit unterstützt werden. Microsoft bietet dies nur im Internet Information Server Version 8.0 in Windows 8 und Windows Server 2012. Auch IIS Express 8.0 kann WebSockets, aber der Visual Web Development Webserver (auch in der aktuellen Version in Visual Studio 2012) ist da außen vor. Zu beachten ist, dass auf Windows 8 und Windows Server 2012 die WebSocket-Unterstützung eine optionale Funktion ist, die über die Systemsteuerung bzw. den Servermanager erst installiert werden muss. Zum Programmieren der WebSockets auf dem Server benötigt man dort WCF 4.5 oder ASP.NET 4.5.

Abbildung 8: WebSocket-Upgrade im HTTP-Monitor „Fiddler“ betrachtet

ASP.NET stellt für WebSockets die Klasse Microsoft.Web.WebSockets.WebSocketHandler bereit, die als Basisklasse für einen ASP.NET-Handler dient, der WebSockets-Anfragen entgegennimmt. In dem Handler müssen die Methoden OnOpen(), OnMessage() und OnClose() überschrieben werden (Listing 5). Die Nachrichten sendet man über eine anonyme Klasse, wodurch man ohne großen Aufwand irgendwelcher Metadaten das Nachrichtenformat ändern oder erweitern kann. Dem untypisierten JavaScript-Client ist sowieso egal, was er kriegt. Er macht aus allem, was per JSON ankommt, ein JavaScript-Objekt.

Das folgende Beispiel realisiert einen Chat (Abb. 9), dem die Clients beitreten und dann vom Webserver über neue Nachrichten aktiv informiert werden. Das Listing 6 zeigt einen Client für den Chat in JavaScript, wobei das JavaScript-Objekt WebSocket verwendet wird.

Abb. 9: Chat-Implementierung mit WebSockets

Listing 5: ASP.NET 4.5 Handler für WebSocket-basierten Chat
<%@ WebHandler Language="C#" Class="chat.ChatHttpHandler" %>  using System;  using System.Collections.Generic;  using System.Linq;  using System.Web;  using Microsoft.Web.WebSockets;   namespace chat {   public class ChatHttpHandler : IHttpHandler  {    public void ProcessRequest(HttpContext context)    {     if (HttpContext.Current.Application["count"] == null) HttpContext.Current.Application["count"] = 0;     HttpContext.Current.Application["count"] = (int)HttpContext.Current.Application["count"] + 1;     string user = "User#" + HttpContext.Current.Application["count"];    if (context.Request.Cookies["username"] != null)     {      user = context.Request.Cookies["username"].Value;     }      if (context.IsWebSocketRequest)     {     context.AcceptWebSocketRequest(new ChatWebSocketHandler(user));     }    }    public bool IsReusable   {    get    {     return false;     }   }  }    public class ChatWebSocketHandler : WebSocketHandler  {   private string user;    private System.Web.Script.Serialization.JavaScriptSerializer serializer = new System.Web.Script.Serialization.JavaScriptSerializer();    private static WebSocketCollection chatapp = new WebSocketCollection();    public ChatWebSocketHandler(string username)    {    user = username;    }    public override void OnOpen()   {    chatapp.Add(this);      chatapp.Broadcast(serializer.Serialize(new    {     type = MessageType.Join,      from = user,      value = user + " hat den Chat betreten!",      otherData = "xy"    }));    }    public override void OnMessage(string message)    {    var m = serializer.Deserialize(message);      switch (m.Type)     {     case MessageType.Broadcast:       chatapp.Broadcast(serializer.Serialize(new      {       type = m.Type,        from = user,         value = m.Value      }));       break;     default:      return;    }   }    public override void OnClose()   {    chatapp.Remove(this);     chatapp.Broadcast(serializer.Serialize(new    {     type = MessageType.Leave,     from = user,     value = user + " hat den Chat verlassen."    }));   }    enum MessageType   {    Send,    Broadcast,    Join,    Leave   }    class Message   {    public MessageType Type { get; set; }    public string Value { get; set; }   }   } }
Listing 6: Client für WebSocket-basierten Chat (JavaScript)
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="chatASHX.aspx.cs" Inherits="chat.ChatPage" MasterPageFile="~/WWWings.Einfach.master" %>                                 

Chat (komplexe Nachricht / Server ist ASP.NET Handler)

[ header = Neuheiten in ASP.NET Web Forms 4.5 – Teil 3 ]

Typisierte Datenbindungsausdrücke

Datensteuerelemente in ASP.NET Web Forms besitzen seit den ersten Tagen von ASP.NET neben fest definierten Spalten- und Zeilenvorlagen die Möglichkeit, über so genannte freie Vorlagen (Template Fields) die Gestaltung einer Spalte (z.B. im GridView-Steuerelement) bzw. Zeile (z. B. im DetailsView-Steuerelement) frei mit beliebigen HTML-Tags in der ASPX-Seite zu definieren.

Ein Template Field enthält verschiedene Vorlagenarten, z. B. Header Template, Item Template, Alternating Item Template, Edit Item Template und Footer Template. Jede Vorlage besteht aus festen und dynamischen Bestandteilen, wobei die dynamischen Bestandteile durch ein <%# %> einzurahmen und die Verweise auf Eigenschaften des aktuellen Datenelements mit Eval() oder Bind() abzurufen sind. Dabei ist Eval() eine Einweg- und Bind() eine Zweiwege-Datenbindung.

Listing 7 zeigt ein Template Field mit Item Template, in dem mit Eval() auf die Eigenschaft „FreiePlaetze“ aus den angebundenen Flug-Objekten Bezug genommen wird. Dabei sind Datentypkonvertierungen zwingend notwendig, da Eval() als Rückgabetyp nur das universelle System.Object deklariert.

In ASP.NET 4.5 kann dies eleganter definiert werden, indem man in dem Datensteuerelement mit der Eigenschaft ItemType deklariert, welcher Klasse die gebundenen Objekte angehören, und dann in der Vorlage mit Item.Eigenschaftname Bezug auf das gebundene Objekt nimmt (Listing 8). Typkonvertierungen entfallen dabei. Visual Studio 2012 stellt IntelliSense-Eingabeunterstützung sowohl für die Eingabe von ItemType als auch für die Eigenschaften von Item bereit. Zu beachten ist aber, dass typisierte Datenbindungsausdrücke nur mit expliziten Geschäftsobjektklassen funktionieren – bei untypisierten Datencontainern, wie einem Dataset, ist dies nicht möglich, da die Entwicklungsumgebung den Inhalt nicht kennen kann und Item.Eigenschaftname auch nicht zum Ziel führen kann. Wieder ein Grund mehr, zukünftig auf Datasets zu verzichten und sich mit objektrelationalem Mapping zu beschäftigen.

Listing 7: Untypisierte Datenbindungsausdrücke mit „Eval()“
                     ...                  <%#   Convert.ToInt32(Eval("FreiePlaetze")) < 10 ?        "gut" : (Convert.ToInt32(Eval("FreiePlaetze")) < 100 ? "mittel" : "schlecht")  %>                  
Listing 8: Typisierte Datenbindungsausdrücke mit ItemType und Item
                     ...                  <%#  Item.FreiePlaetze < 10 ? "gut" : (Item.FreiePlaetze < 100 ? "mittel" : "schlecht")  %>                  
Fazit

Die Verbesserungen in Hinblick auf HTML5-Tags und die WebSockets, die auch zur HTML5-Sphäre hinzuzuzählen sind, stellen sehr begrüßenswerte Erweiterungen für ASP.NET Web Forms dar. Gerade bei den WebSockets zeigt ASP.NET einmal mehr, wie effizient man dort programmieren kann. Auch die typisierten Datenbindungsausdrücke steigern die Effizienz beim Programmieren mit Web Forms. Das waren aber bei weitem noch nicht alle neuen Funktionen in ASP.NET 4.5. In der nächsten Ausgabe geht es in einem zweiten Teil um die neue modellbasierte Datenbindung (Model Binding) und verschiedene Features zur Leistungssteigerung.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -