Neue Möglichkeiten mit Server-Steuerelementen

  • Artikel

Veröffentlicht: 15. Feb 2001 | Aktualisiert: 16. Jun 2004

Von George Shepherd

Serverseitige Steuerelemente basieren auf Code, der auf dem Server läuft. Sie werden mit Standard-HTML oder DHTML auf dem Client angezeigt und kommunizieren mit dem Server über das HTTP-Protokoll.

Steuerelemente für die Serverseite (oder "server-side controls", wie es in der Dokumentation heißt) sind im Prinzip ganz normale anwenderdefinierte Steuerelemente (also "Custom Controls"). Eigentlich sind wir aber alle der Ansicht, solche anwenderdefinierten Steuerelemente gäbe es nun schon seit Jahren, nicht wahr? Da wären zum Beispiel VBXe, so Anfang der Neunziger. 1994 dann die OLE-Steuerelemente. Und 1996 ging die Geschichte mit den ActiveX-Steuerelementen los.
Eine wichtige Gemeinsamkeit dieser Steuerelemente liegt in dem Umstand, dass sie alle auf der Seite des Clients liegen. Die serverseitigen Steuerelemente unterscheiden sich nun dadurch, dass sie, wie die Bezeichnung schon andeutet, auf dem Server liegen. Warum sollte nun jemand auf die Idee kommen, Steuerelemente auf dem Server unterzubringen, wo man sie doch einfach auf der Maschine des Clients installieren kann?

* * *

Auf dieser Seite

Das Problem mit der Erweiterung der Browser Das Problem mit der Erweiterung der Browser
Maskenaufbau auf der Serverseite Maskenaufbau auf der Serverseite
ASP versus ASP+ ASP versus ASP+
Serverseitige Steuerelemente Serverseitige Steuerelemente
Ein einfaches Steuerelement Ein einfaches Steuerelement
Der arbeitsreiche Lebenslauf eines Steuerelements Der arbeitsreiche Lebenslauf eines Steuerelements
Einsatz eines Steuerelements auf einer Webseite Einsatz eines Steuerelements auf einer Webseite
Fazit Fazit

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Bild01

Das Problem mit der Erweiterung der Browser

Die Schnittstelle zum Anwender lässt sich in einem Browser nicht so ohne weiteres mit Steuerelementen erweitern, die auf dem Client liegen. Damit das funktionieren kann, muss der Browser nämlich die entsprechende Technik beherrschen. Wenn Sie zum Beispiel in einem Browser ein ActiveX-Steuerelement für die Kommunikation mit der Website einsetzen möchten, muss der Browser den Umgang mit ActiveX-Steuerelementen beherrschen. Damit er es kann, braucht der Browser eine Handvoll COM-Schnittstellen. In ähnlicher Weise ist eine Website, die Java-Anwendungen einsetzt, auf Browser angewiesen, die damit umgehen können.
In der Praxis kann man nicht davon ausgehen, dass jeder Anwender die allerneueste Version eines bestimmten Browsers benutzt. Das ist einfach unrealistisch. Außerdem sind Browser nicht die einzige Kundschaft, die es zu berücksichtigen gilt. Heutzutage benutzen die Leute WAP-Telefone, Minicomputer mit Windows CE und sonstige tragbare Geräte. Und wer weiß schon, was morgen in Mode ist. Wenn Sie Ihre Website also von Java-Anwendungen und ActiveX-Steuerelementen abhängig machen, werden sie solche Kunden nicht erreichen, die nichts mit Java und ActiveX anfangen können.
In ASP+ gibt es aber eine Lösung für dieses Dilemma. Delegieren Sie die Verantwortung für die Anzeige der Steuerelemente einfach an den Server.

 

Maskenaufbau auf der Serverseite

Per Definition kann jeder Browser HTML verarbeiten und anzeigen. Wenn Sie also die Schnittstelle zum Anwender nicht durch eine entsprechende Erweiterung des Browsers ausbauen können - warum dann eigentlich nicht den Server so einrichten, dass er dem Anwender die gewünschte Eingabemaske, Webseite oder was auch immer anzeigt? Die dafür geeigneten Steuerelemente nennt Microsoft "Steuerelemente für Webformulare" oder "serverseitige Steuerelemente" (Web Form controls oder server-side controls).
Sicher können Sie den HTML-Code für eine umfängliche Anwenderschnittstelle auch von Hand codieren oder eine ASP-Seite entsprechend programmieren. Was Ihnen Microsoft bietet, ist aber ein etabliertes Grundgerüst und Protokoll für die Erzeugung einer unfangreichen UI auf dem Server.
Die Steuerelemente für Webformulare sind nicht von den Webseiten abhängig, auf denen sie eingesetzt werden, und lassen sich unabhängig von den Seiten anlegen, ändern und verwalten. Der Zugriff auf die öffentlichen Datenfelder, Eigenschaften und Methoden eines solchen Steuerelements kann in der betreffenden Webseite oder im zuständigen äußeren Steuerelement vom Programmcode aus erfolgen.
Außerdem halten sich die Steuerelemente für Webformulare an die übliche Hierarchie. Sie können nämlich andere Steuerelemente beerben, aufnehmen und erweitern. Kurz gesagt, die Steuerelemente für Webformulare helfen Ihnen bei der Entwicklung von Web-Anwendungen, während sie gleichzeitig dafür sorgen, dass sich eine wesentlich größere Client-Gruppe ansprechen lässt.
Steuerelemente für Webformulare werden so konzipiert, das sie sich im kommenden ASP+-Gerüst einsetzen lassen. Sie werden für die allen Sprachen gemeinsame .NET-Laufzeitschicht entwickelt und liegen in Form von DLLs vor, in denen es die Eintrittspunkte gibt, die von der ASP+-Laufzeitschicht erwartet werden. Sobald ASP+ bei der Analyse einer Webseite auf ein solches Steuerelement trifft, legt sie das Steuerelement an und initialisiert es. Wie ActiveX-Steuerelemente bieten auch die Steuerelemente für Webformulare Attribute (Properties), Methoden und Ereignisfunktionen (Events) an. Im Gegensatz zu den ActiveX-Steuerelementen leben sie aber ausschließlich auf dem Server. Im Normalbetrieb werden sie nie auf den Client heruntergeladen.
Lassen Sie uns einen Blick auf die wichtigen Unterschiede zwischen ASP und ASP+ werfen, bevor es an die Funktionsweise dieser neuen serverseitigen Steuerelemente geht.

 

ASP versus ASP+

Im Lauf der letzten Jahre hat sich ASP zu einem sehr nützlichen Werkzeug zum Generieren von HTML-Code entwickelt, der sich in allen möglichen Browsern anzeigen lässt. Das Ausführungsmodell von ASP ist weitgehend linear. Wenn Sie ein ASP-Skript installieren, führt die ASP-Laufzeitschicht das Skript einfach aus. Im Prinzip funktioniert das zwar recht ordentlich, aber etwas langsamer als eigentlich nötig. Außerdem bringen Skripte noch andere Nachteile mit sich.
Im Gegensatz dazu analysiert ASP+ den ASP-Text und generiert für die Ausführung eine Standard-Seitenklasse, die auf der .NET-Laufzeitschicht laufen kann. Die Klasse folgt einem Ausführungsmodell auf Ereignisbasis und die Übertragung der Ausgabedaten (zum Beispiel des generierten HTML-Codes) an den Client ist eine der Phasen in der Ausführung der Seite.
ASP+ definiert zwei Arten von Steuerelementen für Webformulare, nämlich "rohe" Steuerelemente (pagelet controls) und vorkompilierte Steuerelemente (precompiled controls). Die rohen Steuerelemente setzen sich aus HTML, Text, Tags und anderen HTML-Steuerelementen zusammen (Schaltflächen, Textelemente und so weiter). Diese rohen Steuerelemente werden erst bei Bedarf kompiliert (wie auch jede andere ASP+-Seite).
Vorkompilierte Steuerelemente werden in einer Sprache geschrieben, die sich für die gemeinsame Laufzeitschicht kompilieren lässt (CLR, common language runtime) und liegen als DLLs vor. Zu diesen Sprachen gehören derzeit C#, die "verwalteten Erweiterungen" (Managed Extensions) für C++ und Microsoft Visual Basic .NET. Mit Sicherheit werden über kurz oder lang weitere Sprachen von anderen Herstellern folgen. Ich möchte mich im folgenden auf die vorkompilierten Steuerelemente konzentrieren.

 

Serverseitige Steuerelemente

Es sprechen eine ganze Reihe von Gründen für den Einsatz von anwenderdefinierten serverseitigen Steuerelementen. Sie haben nicht nur den angenehmen Effekt, eine umfassende Gestaltung der Anwenderschnittstelle zu ermöglichen, die sich nach den Gegebenheiten der Client-Maschinen richten kann, sondern sie erlauben auch die Aufteilung des Programms in Code und Inhalt. Das Programmiermodell von ASP+ ermöglicht die Trennung des HTML-Codes vom ausführbaren Code. Durch die Trennung von Darstellung und Ausführungslogik lässt sich jeder Teil unabhängig vom anderen entwickeln.
Serverseitige Steuerelemente stellen eine schöne Gelegenheit zur Kapselung von wiederverwendbarem Code dar und können weitgehend eigenständig sein. Dann kann der Entwickler der Seite sie quasi als HTML-Tag auf der Seite unterbringen.
Und schließlich vereinfachen serverseitige Steuerelemente auch die Programmiermodelle der Anwendungen. Durch die Kapselung der gewünschten Funktionalität in einem Steuerelement können sich die Seitenentwickler dieser Funktionalität bedienen, indem sie die Attribute des Steuerelements entsprechend setzen und auf die Ereignismeldungen reagieren. Der wichtigste Punkt dürfte die Erleichterung der Verwaltung von spezialisierten Steuerelementen sein.
Zur Entwicklung solcher Steuerelemente sollte man etwas von ASP+ verstehen, etwas von HTML und ein wenig von C++ (oder C# oder Visual Basic). Ich möchte die Architektur der Steuerelemente zuerst an einem C#-Beispiel vorstellen und dann auf ein ähnliches Steuerelement eingehen, das mit Visual Basic erstellt wird.

 

Ein einfaches Steuerelement

Auf der .NET-Plattform müssen sich auch Steuerelemente, die unter ASP+ laufen, an die CLR-Spezifikation halten. Derzeit stehen als verwendbare Sprachen C#, Visual Basic .NET und die Managed Extensions für C++ zur Verfügung. Listing L1 zeigt ein sehr einfaches Steuerelement, das in C# geschrieben wurde. Seine einzige Aufgabe besteht darin, einen einfachen HTML-Text an einen Browser zu übermitteln, der irgendwo dort draußen im Internet auf die Daten wartet.
L1 Ein einfaches Steuerelement

/*======================= 
Simple Control 
========================*/ 
using System; 
using System.Web; 
using System.Web.UI; 
using System.Web.UI.WebControls; 
namespace MSDNSamples 
{ 
    public class SimpleCtl : Control 
    { 
        public SimpleCtl() {} 
        protected override void Render(HtmlTextWriter output) 
        { 
            string htmlText = "<head> What's up? </head>"; 
            output.WriteLine(htmlText); 
        } 
    } 
}

Obwohl es sich fast schon um das einfachste Steuerelement handelt, das man überhaupt entwickeln kann, ist es trotzdem vollständig und lässt sich in eine funktionierende DLL kompilieren. Da wir mit C# Neuland betreten, weist es zudem einige Eigenheiten auf, die noch einer Erwähnung wert sind, nämlich die Namensräume, die C#-Syntax und die Ausgabefunktion Render. Schauen wir uns diese Punkte etwas genauer an.
Namensräume Statt die herkömmlichen Kopfdateien einzubinden, wie man sie von C und C++ her kennt, arbeitet C# mit Namensräumen. Namensräume dienen zur besseren Organisation der C#-Anwendungen, indem sie zusammengehörige Klassen, Schnittstellen, Strukturen, Aufzählungen und Delegierte zusammenfassen. Die using-Direktive weist das C#-Programm an, den genannten Namensraum zu benutzen. Zu den Namensräumen, die ein serverseitiges Steuerelement benutzt, gehören System, System.Web, System.Web.UI und System.Web.UI.Controls.
Der Namensraum Systemumfasst Systemdienste wie zum Beispiel die Aktivierung und Serialisierung von Klassen. Im Namensraum System.Web gibt es Web-orientierte Systemdienste wie die HTTP-Verwaltung. System.Web.UI organisiert Dienste wie die Verwaltung der Steuerelemente und die Verwaltung von kaskadierenden HTML-Stylesheets. System.Web.UI.Controls schließlich enthält die Definition der Control-Klasse zur Erstellung des Steuerelements.
Die Klasse Control Die Control-Klasse definiert die Attribute (Properties), Methoden und Ereignisse (Events), die alle serverseitigen Steuerelemente im ASP+-Rahmen gemeinsam haben. C# beherrscht die Vererbung, ähnlich wie C++, so dass die Entwicklung eines Steuerelements im Prinzip in der Ableitung einer neuen Klasse und der Überschreibung der entsprechenden virtuellen Funktionen besteht. Allerdings werden diese Funktionen in C# überschreibbare Funktionen genannt (overridable functions). C# kennt das Schlüsselwort override, mit dem sich der Aufruf der korrekten Version der Funktion erzwingen lässt. Die Control-Klasse enthält die Infrastruktur, die für serverseitige Steuerelemente auf der .NET-Plattform erforderlich ist. Für unsere Zwecke ist in diesem Zusammenhang die Funktion Render wichtig.
Serverseitige Anzeige der Steuerelemente Die Informationen, die Sie in der Render-Methode Ihres Steuerelements unterbringen, bestimmen das Aussehen des Steuerelements. Render hat ein einzelnes Argument des Typs HtmlTextWriter. HtmlTextWriter abstrahiert die Einzelheiten der Übertragung des HTML-Inhalts an den Browser. Dafür stehen HtmlTextWriter eine ganze Reihe von Funktionen zur Verfügung. Die eine, die im Listing L1 auftaucht, ist WriteLine. Sie nimmt einen C#-String an und schickt ihn zum Browser. Andere Methoden von HtmlTextWriter sind zum Beispiel WriteLineNoTabs, WriteBeginTag und WriteEndTag.

 

Der arbeitsreiche Lebenslauf eines Steuerelements

Ein serverseitiges Steuerelement ähnelt einem endlichen Automaten. Es hat einen bestimmten Lebenslauf und eine Reihe von Zuständen, in denen es vorliegen kann. So kann sich das Steuerelement zum Beispiel im Ladezustand befinden, auf eine Übermittlung antworten oder einfach terminieren. In der Klasse Control gibt es die Methoden und Properties, mit denen sich die Ausführung einer Seite steuern lässt, einschließlich des Ansichtszustands (view-state), der Bearbeitung rückgesendeter Daten (postback data), der Reaktion auf rückgesendete Ereignismeldungen und der Ausgabe der Anzeigedaten. Zur Implementierung eines serverseitigen Steuerelements gehört die Ableitung einer neuen Klasse von Control und die Überschreibung bestimmter Methoden.
Ein kurzer Überblick über den typischen Lebenslauf einer Seite eignet sich sehr schön, um die Funktionsweise eines serverseitigen Steuerelements zu verdeutlichen. Während die Seite geladen wird, analysiert die ASP+-Laufzeitschicht die Seite und generiert eine Page-Klasse für die Ausführung. Die Page-Klasse, die sich von der Control-Klasse ableitet, stellt einen Baum mit serverseitigen Steuerelementinstanzen auf und bevölkert ihn. Sobald dieser Baum fertig ist, beginnt die Page-Klasse mit einer Ausführungssequenz, die sowohl den Code der ASP+-Seite als auch die serverseitigen Steuerelemente an der Bearbeitung der Anfrage und der Anzeige der Seite teilhaben lässt.

Werfen wir nun einen Blick auf den Lebenslauf eines einzelnen Steuerelements. Das Kommunikationsprotokoll für ein serverseitiges Steuerelement ist unterteilt in Aufrufe von etablierten, wohlbekannten Methoden und der Bearbeitung der Rücksendungen.
In Reaktion auf die Anforderung der Seite ruft die ASP+-Seite zuerst die Init-Funktion des Steuerelements auf. Darin werden die erforderlichen Initialisierungen erledigt. Anschließend erhält das Steuerelement die Gelegenheit, seine Anzeige zu regeln. Die Informationen über den Anzeigezustand sind während des Init-Aufrufs nicht verfügbar. Daher gibt es im Steuerelement zu diesem Zweck explizit eine Funktion LoadViewState. Das Steuerelement verwaltet seinen Anzeigezustand in einer Sammlung namens Control.State. Mit der State-Methode können Sie die internen Zustandsdaten zwischen den Seitendarstellungen rekonstruieren.
Gelegentlich erhält eine Seite eine Rücksendung, einen "Postback". Eine Seite kann nicht nur infolge eines Navigationsvorgangs aktiviert werden, sondern auch als Ergebnis einer Rücksendung von einer bereits auf dem Client angezeigten Instanz derselben Seite. Denken Sie zum Beispiel an ein Anmeldeformular mit mehreren Textfeldern, das zurückgeschickt und überprüft werden muss. Man kann solch eine Rücksendung als Gelegenheit zur Aktualisierung der Seite betrachten. Ein Steuerelement erhält dabei die Gelegenheit, alle eintreffenden Daten zu bearbeiten und sein Objektmodell und seinen internen Zustand entsprechend zu aktualisieren. Das ist erforderlich, damit der sichtbare Zustand und der interne Zustand des Steuerelements übereinstimmen. Rücksendungen erfolgen über Schnittstelle IPostBackDataHandler.
Sobald die Seite aktiviert ist, muss das Steuerelement herausfinden, wann es geladen wird. Die Steuerelemente haben die Gelegenheit, die OnLoad-Methode zu überschreiben und Arbeiten auszuführen, die bei jeder eintreffenden Seitenanforderung gleich sind (zum Beispiel die Vorbereitung einer Datenbankabfrage oder die Aktualisierung eines Zeitmessers auf der Seite). Vielleicht muss ein Steuerelement den Client darüber informieren, dass sich die Daten geändert haben. Das geschieht in der Phase der Postback-Änderungsnachricht. Die Steuerelemente melden sich in dieser Phase mit entsprechenden Ereignismeldungen, wenn sich Werte im Formular oder Steuerelement zwischen der letzten und der aktuellen Rücksendung geändert haben.
Die Aktionen des Clients, die zur Rücksendung der aktuellen Daten geführt haben, werden von den Steuerelementen in der Postback-Bearbeitungsphase bearbeitet. So könnte zum Beispiel eine serverseitige Schaltfläche die Rücksendung bearbeiten, die der Anwender mit seinem Klick ausgelöst hat, und auf dem Server das entsprechende OnClick-Ereignis melden.
Durch die Überschreibung der Funktion PreRender können sich Steuerelemente die Gelegenheit für kurzfristige Aktualisierungen verschaffen, die unmittelbar vor der Abspeicherung des Zustands oder vor der Ausgabe stattfinden müssen.
Seinen Anzeigezustand kann ein Steuerelement durch die Überschreibung der Methode SaveViewState speichern. Damit ändert es die State-Sammlung. Die Zustandsinformation eines Steuerelements wird unmittelbar danach von der Sammlung Control.State in ein Stringobjekt übertragen.
Die wohl wichtigste Funktion eines Steuerelements ist Render. Die Steuerelemente benutzen die Render-Klasse zur Erzeugung der HTML-Ausgaben für den Browser. Wenn für eine ASP+-Seite die Zeit gekommen ist, sich selbst im besten Lichte darzustellen, geht ASP+ über die gesamte Liste der Steuerelemente, die auf den Seiten angelegt worden sind, und fordert jedes durch den Aufruf seiner Render-Methode auf, sich selbst darzustellen.
Zum Schluss brauchen die Steuerelemente noch die Gelegenheit, nach dem Ausladen einer Seite aus dem Speicher aufzuräumen. Das können die Steuerelemente in ihrer Methode Dispose tun.
Soviel zum Lebenslauf eines serverseitigen Steuerelements. Die naheliegende nächste Frage lautet: "Wie benutzt man ein Steuerelement auf einer Seite?"

 

Einsatz eines Steuerelements auf einer Webseite

Die Syntax für den Einsatz eines Steuerelements auf einer ASP+-Seite ist nicht schwierig. Die folgenden Zeilen zeigen eine sehr einfache ASP+-Seite, die ein Steuerelement lädt.

<%@ Register TagPrefix="MSDN" Namespace="MSDNSamples" %> 
<html> 
<body> 
<MSDN:SimpleCtl runat="server"/> 
</body> 
</html> 
</pre></font>

Die erste Zeile auf dieser ASP+-Seite deklariert ein Tag namens MSDN, das als Zweitname für den Namensraum MSDNSamples dient. (Das entspricht der Namensraumdeklaration in Listing L1.) Beachten Sie auch das Attribut runat="server". Es weist darauf hin, dass es sich bei SimpleCtl um ein serverseitiges Steuerelement handelt.
Diese Seite wirft zuerst die Tags html und body aus. Dann kommt das Elaborat der Render-Funktion des Steuerelements. Anschließend werden die Tags body und html abgeschlossen, und die Seite ist fertig.
Zum Test bringen Sie die Seite einfach auf einem Server unter und verweisen via HTTP auf diese Seite. Beim benutzten Verzeichnis muss es sich um ein virtuelles Verzeichnis des IIS handeln. Richten Sie mit dem IIS-Administrationsprogramm ein virtuelles Verzeichnis ein, in dem der ASP+-Code liegt.
In einer der nächsten Kolumnen möchte ich Ihnen ein etwas umfangreicheres Steuerelement vorstellen.
Serverseitige Steuerelemente lassen sich nicht nur in C# entwickeln, sondern auch in Visual Basic. Die Syntax ist sehr ähnlich. Listing L2 zeigt, wie sich dasselbe Steuerelement in Visual Basic implementieren lässt.
L2 Einfaches Steuerelement in Visual Basic

Imports System 
Imports System.Web.UI 
Namespace MSDNSamples 
Public Class SimpleCtlInVB 
Inherits Control 
Overrides Sub Render (writer as HtmlTextWriter) 
Writer.Write("<h1>What's up in Visual Basic? </h1>") 
End sub 
End class 
End namespace

Der Visual Basic-Code importiert dieselben Namensräume wie das C#-Programm. Dann definiert er eine Klasse, die von Control abgeleitet wird, und überschreibt deren Render-Methode. Auch dieser Code lässt sich zu einer DLL kompilieren, die den String "What's up in Visual Basic?" ausgibt, wenn sie als serverseitiges Steuerelement in einem Browser gezeigt wird.

 

Fazit

Das war ein grober Überblick über die neuen serverseitigen Steuerelemente aus dem Hause Microsoft. ActiveX-Steuerelemente haben sich schon als ungemein nützlich erwiesen, solange sie in relativ genau bekannten Client-Umgebungen eingesetzt werden. Wenn Sie allerdings keine genauen Vorstellungen davon haben, mit welcher Umgebung Ihr Kunde arbeitet, dürften sich serverseitige Steuerelemente als die bessere Wahl erweisen.
In einer der nächsten Kolumnen möchte ich Ihnen ein wesentlich umfassenderes Steuerelement vorstellen. Außerdem möchte ich etwas tiefer in die Technik der serverseitigen Steuerelemente einsteigen, zum Beispiel in die Verwaltung der Anzeigezustände und in den Umgang mit Rücksendungen (Postbacks).