ASP.NET (I) -
Einführung ins "Next Generation"-Programming

Aufgrund zahlreicher Anfragen haben wir uns entschlossen, von dieser Ausgabe an, eine mehrteiligen Artikel über ASP.NET zu bringen. Es sollen die Unterschiede zu ASP 3.0 aufgezeigt werden, Verbesserungen bewertet und selbstverständlich auch Code-Beispiele gebracht werden. Dieser Artikel basiert auf der Beta 1 des MS.NET Frameworks. Kurzes Experimentieren mit der soeben erschienenen Beta 2 zeigt, dass die vorgestellten Beispiele auch mit der neuen Beta 2 funktionieren.

Wir raten Ihnen aber dringend davon ab, bereits heute Web-Seiten oder Web-Services, die auf der Beta 1 basieren, ins Netz zu stellen! Es werden noch so viele Änderungen bis zur endgültigen Version eingearbeitet, dass es mit absoluter Sicherheit zu Inkompatibilitäten kommen wird! Lesen Sie hier auch früher erschienene Artikel zu ASP.NET und MS.NET!

1. Grundsätzliche Neuerungen

1.1 Weniger und schnellerer Code

Zahlreiche bereits in ASP.NET eingebaute Hilfsmittel, wie etwa die Server Controls, helfen ihnen, einen schlankeren, besser von HTML abgegrenzten und auch deutlich reduzierteren Code zu schreiben. Bisher musste man Skript-Code schreiben, wenn man beispielsweise die Kontrolle über den Session-Zustand auch über mehrere Webseiten hinweg benötigte. Dies ist nun nicht mehr notwendig, da eine solche Funktionalität bereits "out-of-the-box" vorhanden ist.

Die Tage des endlosen Spaghetti-Codes in ASP 3.0 sind ebenfalls gezählt, da strukturiertes Programmieren jetzt unterstützt wird. Dies vereinfacht auch das "Wiederverwenden" von Code in neuen Projekten. Durch die Verwendung von Programmiersprachen, die echte Objektorientierung beeinhalten, sollte der Aufbau von eigenen Bibliotheken, die leicht wieder verwendet werden können, kein Problem sein.

Stichwort: reduzierter Code - Code behind Forms lassen den Code deutlich schlanker werden. Dieser "Code behind" wird beim Kompilieren der ASP-Seite erzeugt, der in einer kompilierten Basis- Klasse steht. Die Aufgabe der include-Files übernehmen die User-Controls, die eben eigenen Code leichter verwendbar machen. Stichwort: schnellerer Code - ASP.NET verwendet kompilierten Code. Wurden bisherige ASP-Seiten bei jedem Aufruf neuerlich interpretiert, wird jetzt der ASP.NET-Code beim erstmaligen Aufruf in eine .NET-Klasse kompiliert. Die Klasse wird im Cache gehalten und bei jedem neuen Aufruf der Seite nur mehr aus dem Cache geholt. Änderungen an der Seite werden automatisch erkannt, die Seite neuerlich kompiliert und die neue Klassen-Version wird gegen die Alte im Cache getauscht.

Das dies eine rasante Geschwindigkeitsverbesserung darstellt ist wohl jedem klar! In Zusammenarbeit mit dem neuen ADO.NET sollte der "Flaschenhals" Datenbankzugriff in ASP-Seiten möglicherweise neu definiert werden. Eventuell kann man mit der Variante der im Cache gehaltenen .NET-Klassen auch jene allen ASP-Entwicklern bekannten ärgerlichen Probleme mit dem Cachingverhalten des Internet Explorers umgehen.

1.2 Typen- und Variablensicherheit/COM-Komponenten

Bisher gab es ja keine explizite Typendeklarationen, wie man es beispielsweise in Visual Basic oder C++ gewohnt war. Alle Variablen wurden als Variant behandelt, belegten daher auch gleichviel an Speicher, egal ob es sich um eine Integervariable oder eine Stringvariable handelte. Dies führte spätestens dann zu Problemen, wenn sie auf eine COM-Komponente zugreifen wollten und sich dann herausstellte, dass es eben nicht möglich ist, eine Zahl einfach zu einem Datum hinzuzufügen. ASP.NET sorgt also für eine strenge Typen- und Variablensicherheit.

Wer bisher Komponenten entwickelte, verwendete und weiterentwickelte fand sich selber rasch in der "DLL-Hölle" wieder. Registrieren, deregistrieren, Versionskompatibilität und und... neue Dll kann nicht kompiliert werden, alte Dll ist gelockt, kein Zugriff erlaubt, Web-Server und diverse Dienste anhalten, stoppen, durchstarten, Registry nach alten Dll- Einträgen durchforsten, löschen ... Web-Server starten, kompilieren, registrieren - Ergebnis: DLL FUNKT NICHT! Jeder VB-Entwickler, der ASP-Applikationen programmiert, hat dies in der einen oder anderen Form, in dieser oder einer anderen Reihenfolge mitgemacht und kann daher den Begriff "DLL-HÖLLE" sehr gut einschätzen! Nun ist jede ASP.NET-Seite selber eine "COM-fähige" Komponente - im Gegensatz zu den alten ASP-Seiten, mit denen einfach nur der Aufruf einer COM-Komponenten-Schnittstelle möglich war. Dies bedeutet, dass viele dieser Versionskonflikte, Updateschwierigkeiten und Integrationsprobleme gelöst wurden.

1.3 Code-Trennung/Browserkompatibilität/XML

Bis jetzt war es nicht wirklich sinnvoll möglich, HTML-Code und Script-Code für ASP-Seiten wirklich zu trennen. In schlecht programmierten Seiten wurde der Parser ständig zwischen HTML und ASP hin- und hergeschalten, was natürlich zu eklatanten Performance-Problemen führte. Mit ASP.NET wird jedoch eine Code-Separierung vollständig möglich!

Auch alte ASP-Seiten versprachen zumindest in der Theorie weitgehende Browserkompatibilität. Aber nachdem ASP nunmal HTML-Code an den Client zurück gibt, führte dies zu den ganz normalen Browserunzulänglichkeiten, je nachdem welcher Browser denn nun clientseitig verwendet wurde. Auch dies hat nun ein Ende! Verschiedenste serverseitige Komponenten liefern jetzt einen Code, der ganz auf den jeweiligen Browser zugeschnitten ist und AUI (Adaptive User Interface) unterstützt die Ausgabe auf anderen Plattformen, zum Beispiel auf WAP-Handys.

Selbstverständlich trotzt ASP.NET nicht dem Zug der Zeit und der lautet: XML everywhere! In Verbindung mit ADO.NET unterstützt ASP.NET die Extensible Markup Language als Datenaustausch-Format optimal.

1.4 Weitere Vorteile

ASP.NET ist skalierbarer und bietet mehr Fehler/Absturz-Toleranz als ASP. Darüber hinaus sind bessere Sicherheitsfeatures integriert und auch das bisherige, mangelhafte Debugging-Verhalten wurde verbessert und ein Trace-Utility eingebaut. Auch das Caching-Verhalten wurde flexibler gestaltet. Doch genug der Ankündigungen und des "Marketing-Speech", gehen wir jetzt zu den eigentlichen Dingen, die den Programmierer interessieren:

2. Feature-Übersicht und deren Programmierung

2.1 Dateiendungen

Eine ASP.NET-Seite erhält nunmehr die Endung .aspx. Wenn nun die dazugehörige aspnet_isapi.dll (in der Beta 1 noch als XSPISAPI.DLL bezeichnet) einen Request mit der File-Endung .aspx bekommt, so wird die Seite in eine .NET-Klasse compiliert oder die bereits vorhandene .NET-Klasse aufgerufen (wenn das entsprechende File bereits vorher einmal aufgerufen wurde). Auch reine HTML-Files, die mit der Endung .aspx abgespeichert wurden, werden so zum Parser gesendet. Selbstverständlich müssen jetzt nicht alle alten ASP-Seiten umbenannt werden, sie werden weiterhin unterstützt. Ihre Aufrufe gehen allerdings so wie bisher an die zugehörige ASP.DLL und sie werden auch nicht kompiliert.

2.2 ASP.NET-Code Einbau

Genau wie bisher leitet man "Fremdcode" in HTML-Seiten durch das <SCRIPT> ein. Defaultmäßig ist in ASP.NET Visual Basic als Scriptsprache voreingestellt. Um eine andere unterstützte Sprache zu verwenden fügen Sie eben in Language="???" die gewünschte Bezeichnung ein. Achtung: VBScript wird nicht länger unterstützt!

    <SCRIPT LANGUAGE="VB" RUNAT="Server">
    ...hier steht der Code....
    </SCRIPT>
    

Dies ist natürlich überflüssig, da ja Visual Basic voreingestellt ist. Im Falle einer anderen Sprache - zum Beispiel C# - sieht dies eben so aus:

    <SCRIPT LANGUAGE="C#" RUNAT="Server">
    ...hier steht der Code...
    </SCRIPT>
    

Wird eine ASP.NET Seite ausgeführt werden eine Reihe von definierten Events durchlaufen. Am Anfang steht der Page_Init Event, der vom Page_Load Event gefolgt wird. Dieser Page_Load Event wird immer ausgeführt und er ist auch der erste auftretende Event, wenn die Seite fertig geladen ist. Wenn Sie also Code ausführen möchten bevor irgendein anderer Event auf ihrer Seite auftritt, so müssen sie diesen Code im Page_Load Event unterbringen:

    <SCRIPT LANGUAGE="VB" RUNAT="Server">
    Sub Page_Load()
    ...hier steht der Code...
    End Sub
    </SCRIPT>
    

Jeder Code, der außerhalb dieser Haupt-Events oder Sub-Prozeduren steht, kann für die Deklaration von globalen Variablen genützt werden. Beim Schliessen des Browers wird zu guter Letzt als Gegenstück der Page_Unload Event ausgeführt.

2.3 Kompatibilität zu XHTML

Gegenwärtig in der Beta 1 des .NET Frameworks wird XHTML von ASP.NET leider nicht unterstützt. Aufgrund der angestrebten Browserkompatibilität liefert der Parser HTML 3.2 aus, während XHTML auf den Spezifikationen von HTML 4.01 basiert. Dieser Konflikt zwischen Browserkompatibilität, Plattform-Unabhängigkeit und doch neueste Entwicklungen zu berücksichtigen wird bis zur endgültigen Public Release von ASP.NET noch einiges an Veränderungen bringen. Generell ist zu sagen, dass aber eine möglichst weitgehende Kompatibilität mit XHTML von Microsoft noch angestrebt wird.

3. Seiten mit ASP.NET

3.1 HTML Server Controls

HTML Server Controls sind eine der spektakulärsten Neuerungen in ASP.NET. Diese Controls sind praktisch HTML-Elemente, die wiederum Attribute beeinhalten, die am Server laufen: Quasi Formular-Kontrollen. Die Struktur der verwendeten Tags wird ihnen bekannt vorkommen. Der Lernaufwand ist hier nicht sehr hoch, da die Tags eigentlich das Equivalent der client-seitigen Programmierung sind. Die folgenden zwei Code-Beispiele sind also ident - zunächst die neue ASP.NET-Struktur, danach die bisherige traditionelle Programmierung - der Output ist gleich:

    <ASP:ListBox ID="ListBox1" runat="Server">
        <ASP:ListItem>Europa</ASP:ListItem>
        <ASP:ListItem>USA</ASP:ListItem>
        <ASP:ListItem>Afrika</ASP:ListItem>
        <ASP:ListItem>Asien</ASP:ListItem>
    </ASP:ListBox>
    

    <SELECT NAME="ListBox2" SIZE="4">
        <OPTION>Europa</OPTION>
        <OPTION>USA</OPTION>
        <OPTION>Afrika</OPTION>
        <OPTION>Asien</OPTION>
    </SELECT>
    

Sie werden jetzt fragen, wo liegt der Vorteil dieser HTML Server Controls, nachdem der Quellcode ja ungefähr gleich lang ist? Das Server Control erinnert sich daran, welche "Control"-Eigenschaft nun ausgewählt wurde. Sie benötigen also keinen weiteren Code um diesen Zustand an andere Seiten zu übertragen. Wenn Sie nachfolgenden Code in ihren Editor kopieren, danach auf "Absenden" klicken, werden sie sehen, dass sich im Quellcode einiges geändert hat:

    <html>
    <body>
    <form runat="Server">
    <h1>QUERDENKER-TEST:</h1>
    <ASP:ListBox id="ListBox1" runat="Server">
    <ASP:ListItem>Europa</ASP:ListItem>
	 <ASP:listItem>USA</ASP:ListItem>
	 <ASP:listItem>Afrika</ASP:ListItem>
	 <ASP:listItem>Asien</ASP:ListItem>
    </ASP:ListBox>
    <p />
    <input type="submit" value="Absenden">
    </form>
    </body>
    </html>
    

Und hier der Quellcode - nach dem Drücken des "Absenden"-Buttons:

    <html>
    <body>
    <form name="ctrl1" method="post" action="querdenker.aspx" id="ctrl1">
    <input type="hidden" name="__VIEWSTATE" value="YTB6NDQxMjAyMDgxX19feA==db652da4" />
    <h1>QUERDENKER-TEST:</h1>
    <select name="ListBox1" id="ListBox1" size="4">
    <option value="Europa">Europa</option>
    <option selected value="USA">USA</option>
    <option value="Afrika">Afrika</option>
    <option value="Asien">Asien</option>
    </select>
    <p />
    <input type="submit" value="Absenden">
    </form>
    </body>
    </html>
    

Es springt sofort ins Auge, dass ASP.NET zunächst einmal 4 Attribute zum Form-Tag hinzugefügt hat und das runat-Tag entfernt wurde. Method-Tag wurde auf "Post" gesetzt, die Zielseite (action=...) auf die Ursprungsseite geleitet und weiters wurde eine eindeutige ID und ein Namen für das Formular vergeben. Darüber hinaus wurde ein verstecktes Input-Tag eingefügt. In diesem versteckten Feld steckt eigentlich die Logik der HTML Server Controls. Hier wird der Zustand der Form gemerkt. Wenn nun der User auf "Absenden" klickt, erhält der Client nun den HTML-Code mit seiner Auswahl zurück. Auch alle ASP-Tags wurden entfernt und durch die entsprechenden HTML-Tags zur Browser- Darstellung ersetzt. Und merke: Dies alles - die Veränderungen im Form-Tag bzw. das Hinzufügen des versteckten Input-Feldes macht ASP.NET selbständig und erfordert keinerlei zusätzliche Code-Zeilen vom Programmierer!

In der nächsten Ausgabe von querdenker:

Serverseitiges Verarbeiten von Events, die am Client auftreten
Überblick über die ASP.NET Controls
Mit Code-Behind programmieren
ASP.NET Web Services und Configuration
ADO.NET
und vieles mehr ...ab Oktober 2001 - dann schon mit den Beta2-Grundlagen!

XML und kein Ende -
Canonical XML 1.0

Ende März 2001 veröffentlichte das W3C seine neue Empfehlung "Canonical XML". Dabei geht es um es die Übereinstimmung zweier/mehrerer Dokumente, die durch einen bestimmten Algorithmus, hinsichtlich ihrer möglichen unterschiedlichen Entities und Attributanordnungen, trotzdem logisch gleich sein können.

Dadurch soll die Ablösung der DTDs (Document Type Definiton) durch ungleich wirkungsvollere Schemata vorangetrieben werden. Dennoch ist Canonical XML vorerst eine Stufe vor der Einstufung als Working Draft (= Proposed Recommendation).

Schemata beschreiben ebenso wie DTDs die Struktur von XML-Dokumenten, sind aber durch die Möglichkeit, Elemente einfach abzuleiten aus anderen Elementen sowie der optionalen Feststellungsmöglichkeit, wie häufig diese Elemente in einem Kontext erscheinen können, eben wesentlich leistungsfähiger als DTDs. In diesem Zusammenhang verweisen wir auch auf unser querdenker-Archiv, indem Sie weitere Hinweise auf Veröffentlichungen des W3C im Kontext mit XML finden.

Meine Meinung -
Standards,
die keine sind ...

In den letzten Wochen und Monaten haben wieder einige Firmen und Konzerne beschlossen, ihre Kunden für blöd zu verkaufen: Zum Einen AOL, die mit ihrer Zugangssoftware in der Version 6.0 Millionen von Kunden HTML-Email als "Standard" verkaufen und dabei so tun, als ob dies der Defacto-Standard wäre. Zum Anderen eine Reihe von dubiosen Top-Level-Domain-Verkäufern, die Fantasie-Endungen wie .doc, .musik (beliebig erweiterbar) an den ahnungslosen Kunden bringen und damit ebenfalls einen Standard vorgaukeln, der einfach nicht vorhanden ist.

Millionen AOL-Kunden erhalten mit AOL 6.0 nicht nur eine bescheuerte Vorselektierung von Internet- Inhalten, kombiniert mit einem umständlichen Zugang ins Netz, sondern werden gleichzeitig auch noch von den meisten Mailinglisten und E-Mail-Partnern ausgeschlossen, weil diese - zu Recht - keine HTML-Mails akzeptieren. Obendrein war es auch bereits der Fall, dass dieses "Miststück" von proprietärer AOL-Weichware nicht nur nichtabschaltbare HTML-Mails produziert, sondern den Textteil auch noch in Base64 kodiertem Unicode erscheinen lässt.

Die lieben AOL-Kunden werden sich noch wundern, warum sie leider vom E-Mail-Traffic und von vielen Mailinglisten und Usenet ausgeschlossen sind. Damit hat AOL seinen Kunden einen Bärendienst, sprich AOL-Standard erwiesen ...

"Alternative Registrierungsstellen" nennen sich Unternehmen wie etwa Beat-nic. Sie nützen die Langsamkeit der ICANN und das Unverständnis der User dazu, neue Fantasie-Domains zu registrieren, die dann halt leider nur von Wenigen überhaupt angesurft werden können. Damit die neuen Domains im Internet überhaupt sichtbar sind, wären alle Provider gezwungen die neuen Alternativ-Domain-Name Systeme (DNS) zu unterstützen. Und dies wird sicherlich nicht flächendeckend erfolgen. Die Folgen davon sind ein unübersichtlicher Wildwuchs an Domains, die nur von Teilen des Netzes erreichbar sind, eventuell doppelt belegte Domains mit unterschiedlichen Inhalten, kurz: Eine Aufspaltung des Netzes in zahlreiche Unternetze oder eben grober Unfug!

Statt also einer erwünschten Standardisierung (Inhalte, die von allen Usern gesehen, gestaltet und bewertet werden können) den nötigen Nachdruck zu ermöglichen, erfolgt das genaue Gegenteil. Und AOL und gewisse "alternative Registrierungsstellen" sind wiederum nur ein kleiner Teil derjenigen, die ihren proprietären Schwachsinn unters Volk bringen wollen ...

Martin Kratschmer

see-programming

querdenker