Anzeige
Tutorialbeschreibung

Javascript und Ajax - JavaScript goes .NET

Javascript und Ajax - JavaScript goes .NET

Das nun folgende Tutorial ist ein Auszug aus der 7. Auflage des Buches: JavaScript und Ajax von Christian Wenz.

Intelligenz lässt sich nicht am Weg, sondern nur am Ergebnis feststellen. – Garry Kasparov

Kapitel 26 JavaScript goes .NET

In Kapitel 20 haben Sie bereits Microsofts .NET-Technologie anhand eines Web Service im Einsatz gesehen. In diesem Kapitel gehen wir einen Schritt weiter und werfen einen Blick über den Tellerrand: In .NET können Sie sogar mit JavaScript programmieren! Genauer gesagt, in Microsofts JavaScript-Dialekt JScript. Die .NET-Anpassung der Sprache wurde von den Redmondern schlicht JScript.NET getauft. Die Web-Abteilung von .NET heißt ASP.NET – Sie wissen sicherlich, dass ASP für Active Server Pages steht und die alte Microsoft-Technologie für die serverseitige Skriptprogrammierung ist.

Als Voraussetzungen benötigen Sie dieselbe Software, die schon in Kapitel 20 für .NET Web Services (Version 1.x) genannt wurde: einen Microsoft IIS-Webserver sowie das .NET Framework. Standardmäßig wird der Webserver meist so installiert, dass die .NET-Dateien in c:inetpubwwwroot abgelegt werden. Eine ASP.NET-Seite hat die Endung .aspx, deswegen enden auch alle Dateien in diesem Kapitel so. Im Webbrowser rufen Sie dann die Datei über http://localhost/dateiname.aspx auf (und nicht über den Pfadnamen auf der Festplatte). Auch mit ASP.NET 2.0 und dem Visual Web Developer können Sie in JScript.NET entwickeln, allerdings hilft Ihnen die Entwicklungsumgebung nicht dabei. Die Sprache wird aber weiterhin von ASP.NET 2.0 an sich unterstützt.

An dieser Stelle gebe ich nur einen groben Überblick über einige der Möglichkeiten von ASP.NET/JScript.NET. Für weiterführende Informationen sollten Sie Spezialliteratur lesen.


 

 

26.1 Erste Schritte 

Nun wollen wir die Funktionstüchtigkeit von ASP.NET an kleineren Beispielen ausprobieren. Zunächst einmal muss ASP.NET mitgeteilt werden, dass in JScript.NET programmiert werden soll (der Standard ist nämlich eine andere Microsoft-Sprache, Visual Basic). Das geht mit folgender Anweisung:

<%@ Page Language="JScript" %>

Skriptcode wird in ASP.NET vor dem eigentlichen HTML-Code angebracht, und zwar innerhalb der folgenden Tags:

<script runat="server">

// hier kommt der Skriptcode hin

</script>

Besonders wichtig ist hier das Attribut runat="server". Jedes Element, das dieses Attribut hat, ist für ASP.NET sichtbar. Aber auch das Gegenteil gilt: Wenn Sie dieses Attribut vergessen, kann ASP.NET mit dem Element nichts anfangen. Lassen Sie es beispielsweise beim <script>-Tag weg, so wird der dort platzierte Code für clientseitigen JavaScript-Code gehalten und von ASP.NET nicht angerührt.

ASP.NET ist zudem komplett objektorientiert, Sie müssen also alles über Methoden abhandeln. Hilfreich ist hier die reservierte Methode Page_Load(). Diese wird beim Laden der Seite ausgeführt (sie ist also eine Art Pendant zum clientseitigen Gegenstück onload). Hier folgt ein kleines Beispiel. Die Anweisung Response.Write() ist das serverseitige Gegenstück zu document.write() von JavaScript:

<%@ Page Language="JScript" %>

<script runat="server">

function Page_Load() {

   Response.Write("ASP.NET ist einfach zu erlernen");

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

</body>

</html>

Wie zu erwarten, gibt dieses Skript den gewünschten Text aus.


Bilder

Abbildung 26.1     Das erste ASP.NET-Skript

Interessant ist ein Blick auf den erzeugten HTML-Quellcode:

ASP.NET ist einfach zu erlernen

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

</body>

</html>

Sie sehen: Der Text wurde vor dem HTML-Code ausgegeben; der (serverseitige) <script>-Block ist verschwunden: Er wurde auf dem Webserver interpretiert, und das Ergebnis seines Codes, nämlich die Textausgabe, wurde an den Browser geschickt.

Es gibt noch eine weitere, sehr bequeme Möglichkeit, Text mit ASP.NET auszugeben. Dazu müssen Sie zunächst ein textfähiges HTML-Element erstellen, beispielsweise <p> oder <div> oder <span>. Geben Sie diesem Element eine eindeutige ID sowie das schon bekannte Attribut runat="server". Hier ein Beispiel:

<p id="Absatz" runat="server">Text ...</p>

Der Clou: Über die ID können Sie nun auf das HTML-Element zugreifen, und zwar von ASP.NET aus. Dessen Eigenschaft InnerHtml entspricht der Eigenschaft innerHTML (beachten Sie die unterschiedliche Schreibweise), die neuere Versionen des Internet Explorer und Netscape Navigator kennen:

Absatz.InnerHtml = "HTML-Zugriff leicht gemacht";

Hier sehen Sie ein komplettes Listing:

<%@ Page Language="JScript" %>

<script runat="server">

function Page_Load() {

   Absatz.InnerHtml = "HTML-Zugriff leicht gemacht";

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

<p id="Absatz" runat="server">Text ...</p>

</body>

</html>

Bilder

Abbildung 26.2     Der Text wird im <p>-Element ausgegeben.

Wie Sie sehen, wird der Text im Webbrowser ausgegeben. Werfen wir wieder einen Blick auf den erzeugten HTML-Quellcode:

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

 

<p id="Absatz">HTML-Zugriff leicht gemacht</p>

</body>

</html>

Sie stellen fest: Wieder ist der <script>-Block verschwunden; innerhalb des <p>-Elements steht jetzt der angegebene Text (das runat="server" ist ebenfalls nicht mehr da).

26.2 HTML Controls 

Was Sie gerade in Aktion gesehen haben, sind die so genannten HTML Controls von ASP.NET: Durch das Hinzufügen von runat="server" kann (fast) jedes HTML-Element serverseitig ausgelesen und auch modifiziert werden. Sie müssen nie wieder serverseitigen und clientseitigen Quellcode mischen: Ein Designer erstellt das HTML-Gerüst einer Seite, und der Programmierer fügt den Skriptcode hinzu und »füllt« somit das HTML-Grundgerüst mit Daten.

Besonders von Vorteil ist das Ganze natürlich bei Formularen. Hier gibt es allerdings eine Besonderheit: Damit Sie auf die einzelnen Elemente eines Formulars serverseitig zugreifen können, müssen Sie nicht nur diese mit dem Attribut runat="server" versehen – sondern auch das Formular muss mit dem runat-Attribut für den serverseitigen Zugriff freigeschaltet werden.

Auf die entsprechenden Daten in den Formularfeldern können Sie dann mit den Eigenschaften Value zugreifen (bei einigen Formularfeldtypen gibt es Besonderheiten, aber das ist zunächst nicht von Interesse). Denken Sie nur daran, jeweils eine eindeutige ID zu vergeben.

Für das nächste Beispiel ebenfalls noch von Interesse ist das Attribut OnServerClick für HTML-Schaltflächen (<input type="button">). Hier können Sie als Wert den Namen einer ASP.NET-Funktion angeben, die dann – serverseitig – beim Klicken auf die Schaltfläche ausgeführt werden wird:

<input type="button" value="Versenden"

   OnServerClick="Ausgabe" runat="server" />

Die Funktion Ausgabe() steht dann im <script>-Block und hat folgendes Aussehen:

function Ausgabe(o: Object, e: EventArgs) {

   // Code ...

}

Hier sehen Sie eine weitere Besonderheit von ASP.NET und auch eine von JScript.NET: Die Funktion erhält automatisch zwei Parameter, hier o und e genannt. Es ist jedoch eine Vorschrift von .NET, dass jede Variable einen Typ hat. Der Typ ist hier hinter dem Doppelpunkt angegeben. JavaScript kennt eine solche Typisierung von Variablen nicht, deswegen haben alle anderen Kapitel dieses Buches Variablen ohne Typ.

Unser nächstes Beispiel ist etwas länger: Ein Formular mit ein paar Feldern wird erzeugt; auf Mausklick werden dann die Feldeingaben ausgegeben. Dies ist natürlich nur eine Demonstration von ASP.NET; in einer »wirklichen« Anwendung würden die Formulardaten beispielsweise in eine Datenbank geschrieben oder per E-Mail versandt werden. Sie sehen aber bereits hier, wie einfach das eigentlich geht:

<%@ Page Language="JScript" %>

<script runat="server">

function Ausgabe(o: Object, e: EventArgs) {

   var s: String;

   s  = "Name: " + Name.Value + "<br />";

   s += "E-Mail: " + Email.Value + "<br />";

   s += "Buch: " + Buch.Value;

   Absatz.InnerHtml = s;

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

<form runat="server">

Name: <input type="text" id="Name" runat="server" /><br />

E-Mail: <input type="text" id="Email" runat="server" /><br />

Buch: <select id="Buch" runat="server">

   <option value="JS7">JavaScript-Handbuch, 7. Auflage</option>

   <option value="AS">Einstieg in ActionScript</option>

   <option value="WS">Web Services – Grundlagen</option>

   <option value="WSPHP">Web Services mit PHP</option>

</select>

<input type="button" value="Versenden"

   OnServerClick="Ausgabe" runat="server" />

</form>

<p id="Absatz" runat="server"></p>

</body>

</html>

In der Funktion Ausgabe() wird zunächst eine String-Variable deklariert. Auch hier muss der Datentyp angegeben werden:

   var s: String;

Dann werden die einzelnen Formularangaben in dieser Variablen gesammelt, und diese wird dann am Ende im <p>-Element ausgegeben:

   Absatz.InnerHtml = s;

In Abbildung 26.3 sehen Sie das Ergebnis. Es hat den angenehmen Nebeneffekt, dass die Formularfelder nach dem Formularversand automatisch wieder mit den zuvor eingegebenen Werten vorausgefüllt werden. Das ist insbesondere dann wichtig, wenn der Anwender noch Angaben korrigieren muss, beispielsweise fehlende Pflichtfelder.


Bilder

Abbildung 26.3     Formulardaten werden ruckzuck ausgegeben.

 

26.3 Web Controls 

Wie Sie sehen konnten, kann eine bestehende HTML-Seite relativ schnell für ASP.NET umgestellt werden: Alle Elemente, die serverseitig modifiziert werden sollen, müssen mit runat="server" versehen werden.

Die Firma Microsoft versucht jedoch schon seit Jahren – und das ziemlich erfolglos – die Entwicklung von Windows-Anwendungen der Entwicklung von Web-Anwendungen anzugleichen. Die Idee lautet: Wenn die Anwendungen ähnlich erstellt werden können, wird aus einem guten Windows-Entwickler sofort ein fähiger Web-Entwickler. Über diese Folgerung kann man streiten, dennoch gibt es immer wieder Ansätze von Microsoft-Entwicklungsumgebungen, die sowohl für Standalone-Programme als auch für Webseiten verwendet werden können.

Der vorerst letzte Höhepunkt dieser Bestrebungen ist bei ASP.NET realisiert worden und in Visual Studio besonders offensichtlich zu beobachten: Microsoft hat eigene Tags eingeführt, die so genannten Web Controls. Diese beginnen immer mit <asp: und ähneln vom Namen her Windows-Elementen. Hier ein Beispiel: Bei der Windows-Programmierung (mit Visual Studio, aber auch mit Konkurrenzprodukten) steht ein Label-Element immer für einen Text. Nun gibt es bei ASP.NET »zufällig« das Web Control <asp:Label>. Auch hier ist wieder runat="server" Pflicht, und auch hier erfolgt der Zugriff wieder über das id-Attribut. Der einzige Unterschied zu den zuvor gezeigten HTML Controls ist eine andere Eigenschaft für den Text; hier heißt sie Text. Folgendes Beispiel illustriert das:

<%@ Page Language="JScript" %>

<script runat="server">

function Page_Load() {

   Ausgabe.Text = "Web Controls sind recht praktisch";

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

<asp:Label id="Ausgabe" runat="server" />

</body>

</html>

Tags für Web Controls müssen immer abgeschlossen werden, entweder wie gezeigt mit .../> oder mit dem zugehörigen End-Tag. Das wäre hier </asp:Label> gewesen.


Bilder

Abbildung 26.4     Die Ausgabe – wie erwartet

Der Text wird ausgegeben, womit Sie sicherlich gerechnet haben; der HTML-Quellcode im Browser sorgt jedoch für eine kleine Überraschung:

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

<span id="Ausgabe">Web Controls sind recht praktisch</span>

</body>

</html>

Das Web Control wurde also in ein entsprechendes HTML-Element umgewandelt, und zwar in <span>!

Das Beispiel von oben mit dem Mini-Formular lässt sich recht schnell umschreiben. Die Tücken stecken hier im Detail: Die Control-Namen sind neu, und das gilt auch für die Namen der Eigenschaften, über die der Zugriff auf die Formulardaten erfolgt. Deswegen sehen Sie hier ohne weiteren Kommentar den entsprechenden Code:

<%@ Page Language="JScript" %>

<script runat="server">

function Ausgabe(o: Object, e: EventArgs) {

   var s: String;

   s  = "Name: " + Name.Text + "<br />";

   s += "E-Mail: " + Email.Text + "<br />";

   s += "Buch: " + Buch.SelectedItem.Value;

   Absatz.Text = s;

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

<form runat="server">

Name: <asp:TextBox id="Name" runat="server" /><br />

E-Mail: <asp:TextBox id="Email" runat="server" /><br />

Buch: <asp:DropDownList id="Buch" runat="server">

   <asp:ListItem Value="JS7" Text="JavaScript-Handbuch, 7. Auflage" />

   <asp:ListItem Value="AS" Text="Einstieg in ActionScript" />

   <asp:ListItem Value="WS" Text="Web Services – Grundlagen" />

   <asp:ListItem Value="WSPHP" Text="Web Services mit PHP" />

</asp:DropDownList>

<asp:Button Text="Versenden" OnClick="Ausgabe" runat="server" />

</form>

<asp:Label id="Absatz" runat="server" />

</body>

</html>

Aber Web Controls sind nicht nur ein Pendant zu HTML Controls, sie gehen auch weiter. Ein besonders aussagekräftiges Beispiel hierfür ist das folgende dreizeilige Listing:

<form runat="server">

   <asp:Calendar runat="server" />

</form>

Die Browserausgabe sehen Sie in Abbildung 26.5.

Bilder

Abbildung 26.5     Das Calendar-Web-Control im August 2006

Es wird also ein Kalender erzeugt, der sich automatisch im richtigen Monat befindet (es ist auch möglich, den aktuellen Tag zu markieren). Die drei Zeilen ASP.NET-»Code« haben zu etwa 30 Zeilen HTML-Code geführt, der aus über 6500 Zeichen besteht. Damit ist klar, dass Web Controls nicht nur ein Ersatz für HTML Controls sein sollen, sondern eine Erweiterung sind.

26.4 Validation Controls  

Eine häufige Anwendung für JavaScript ist die Validierung von Formularfeldern. Noch besser als eine JavaScript-Validierung ist natürlich eine serverseitige Validierung, denn clientseitiges JavaScript kann ja im Browser ausgeschaltet werden.

Bei der Überprüfung von Pflichtfeldern kann ASP.NET dem Programmierer viel Arbeit abnehmen. Der Einbau einer Formularprüfung erfordert (fast) keine Programmierung. So genannte Validation Controls übernehmen den Rest. Hier sehen Sie ein Beispiel für ein solches Control:

<asp:RequiredFieldValidator runat="server"

   ControlToValidate="Email"

   ErrorMessage="** Geben Sie eine E-Mail-Adresse an" />

Das Formularfeld mit dem id-Attribut "Email" wird überprüft; bei einem Fehler wird die angegebene Fehlermeldung ausgegeben. Neben dieser einfachen Überprüfung für Pflichtfelder können auch komplexere Angaben verifiziert werden, zum Beispiel mit Hilfe von regulären Ausdrücken:

Hier wird das Feld Email zusätzlich noch auf korrekte Formatierung geprüft. Das Attribut Display="Dynamic" ist nicht notwendig; im Beispiel sorgt es nur dafür, dass die Fehlermeldung im Zweifelsfall direkt neben dem zugehörigen Formularfeld ausgegeben wird.

Das Beste: Das war es auch (fast) schon. Validation Controls werden an der Stelle, an der sie im HTML-Code stehen, bei Bedarf durch die angegebene Fehlermeldung ersetzt; Sie sollten die Controls also neben dem jeweiligen Formularfeld platzieren. Hier sehen Sie ein vollständiges Listing:

<%@ Page Language="JScript" %>

<script runat="server">

function Ausgabe(o: Object, e: EventArgs) {

   Page.Validate();

   if (Page.IsValid) {

      var s: String;

      s  = "Name: " + Name.Text + "<br />";

      s += "E-Mail: " + Email.Text + "<br />";

      s += "Buch: " + Buch.SelectedItem.Value;

      Absatz.Text = s;

   }

}

</script>

 

<html>

<head>

   <title>ASP.NET</title>

</head>

<body>

 

<form runat="server">

Name: <asp:TextBox id="Name" runat="server" />

<asp:RequiredFieldValidator runat="server"

   ControlToValidate="Name"

   ErrorMessage="** Geben Sie Ihren Namen an" />

<br />

E-Mail: <asp:TextBox id="Email" runat="server" />

<asp:RequiredFieldValidator runat="server"

   ControlToValidate="Email"

   ErrorMessage="** Geben Sie eine E-Mail-Adresse an"

   Display="Dynamic"/>

<asp:RegularExpressionValidator runat="server"

   ControlToValidate="Email"

   ValidationExpression="w+([-+.']w+)*@w+([-.]w+)*.w+([-.]w+)*"

   ErrorMessage="** Geben Sie eine gültige E-Mail-Adresse an"

   Display="Dynamic"/>

<br>

Buch: <asp:DropDownList id="Buch" runat="server">

   <asp:ListItem Value="JS7" Text="JavaScript-Handbuch, 7. Auflage" />

   <asp:ListItem Value="AS" Text="Einstieg in ActionScript" />

   <asp:ListItem Value="WS" Text="Web Services – Grundlagen" />

   <asp:ListItem Value="WSPHP" Text="Web Services mit PHP" />

</asp:DropDownList>

<asp:Button Text="Versenden" OnClick="Ausgabe" runat="server" />

</form>

<asp:Label id="Absatz" runat="server" />

</body>

</html>

Laden Sie die Seite in den Webbrowser, und versuchen Sie, das Formular unausgefüllt oder mit falschen Angaben abzusenden. Das mögliche Ergebnis sehen Sie in Abbildung 26.6.


Bilder

Abbildung 26.6     Das Formular kann nicht mit Fehlern verschickt werden.

ASP.NET verhindert clientseitig, dass das Formular verschickt wird, wenn die Überprüfungen nicht stattgefunden haben. Dies geschieht auf dem Client, sprich: Hier ist JavaScript mit im Spiel. Ein Blick in den Quellcode offenbart das auch. Zunächst wird eine ASP.NET-eigene Validierungsbibliothek geladen (die Versionsnummer hängt natürlich von der Versionsnummer der verwendeten .NET-Version ab):

<script language="javascript" src="/aspnet_client/system_web/1_1_4322/WebUIValidation.js">

</script>

Die Fehlermeldungen sind auch alle bereits im HTML-Dokument vorhanden:

<span id="_ctl1" controltovalidate="Name" errormessage="** Geben Sie Ihren Namen an" 

evaluationfunction="RequiredFieldValidatorEvaluateIsValid" initialvalue="" 

style="color:Red;visibility:hidden;">** Geben Sie Ihren Namen an</span>

Beachten Sie das style-Attribut – zunächst sind die Meldungen nämlich noch unsichtbar. Sobald jedoch ein Fehler festgestellt wird, werden die roten Texte sichtbar. Die folgende Angabe im <form>-Tag aktiviert schließlich die Validierung beim Formularversand:

onsubmit="ValidatorOnSubmit();"

Sie sehen also – es ist keine große Hexerei, aber viel weniger Arbeit.

Sie fragen sich vermutlich noch, warum die folgende Überprüfung im JScript.NET-Code eingebaut worden ist:

   Page.Validate();

   if (Page.IsValid) {

      // ...

   }

Nun, die Validierung im Webbrowser funktioniert offensichtlich nur bei aktiviertem JavaScript. Viel schlimmer ist jedoch Folgendes: Sie funktioniert in alten .NET-Versionen (1.0, 1.1) nur im Microsoft Internet Explorer, andere Browser bleiben außen vor. Das ist umso verwunderlicher, als dass beispielsweise die aktuellen Netscape-Versionen in JavaScript-Hinsicht die gezeigten Effekte zum »Live-Einblenden« von Fehlermeldungen durchaus unterstützen würden. Aber es soll eben nicht so sein, wie Abbildung 26.7 und Abbildung 26.8 verdeutlichen: Unter Konqueror kann das Formular auch mit Fehlern verschickt werden.

Allerdings gibt es für diese anderen Browser und Browsereinstellungen einen Ausweg: Mit Page.Validate() stoßen Sie manuell die Validierung an. Wenn mindestens ein Validation Control eine Fehlermeldung ausgeben müsste, wird dadurch die Eigenschaft Page.IsValid auf false gesetzt. Deswegen wird genau diese Eigenschaft geprüft. Ist sie true, werden die Formulardaten ausgegeben, andernfalls nicht. Im letzteren Fall allerdings erscheinen dann automatisch die Fehlermeldungen – der Benutzer, der das Formular ausgefüllt hat, muss also seine Eingaben korrigieren, um das Formular verschicken zu können.


Bilder

Abbildung 26.7     Beim Konqueror kann das Formular (zunächst) verschickt werden …


Bilder

Abbildung 26.8     ...doch die »Bestrafung« folgt auf dem Fuße.

In ASP.NET 2.0 funktioniert die Validierung in allen modernen Browsern, aber die Extra-Prüfung ist weiterhin notwendig – JavaScript kann ohne Weiteres abgeschaltet werden. Sie dürfen sich deswegen nie darauf verlassen, dass die Daten im Browser bereits überprüft worden sind.

 

26.5 Fazit

Dieser kleine Exkurs hat Ihnen hoffentlich gezeigt, dass in ASP.NET einige sehr praktische Dinge integriert sind, die die serverseitige Programmierung stark erleichtern können – und dabei müssen Sie (fast) keine neue Sprache lernen, denn JScript.NET und JavaScript sind sich sehr ähnlich. Außerdem haben Sie gesehen, dass Microsofts .NET selbst sehr viel JavaScript-Code erzeugt; die clientseitige Technologie ist also immer noch aktuell und wichtig. Allerdings gibt es auch hier einen Pferdefuß: ASP.NET erzeugt teilweise so viel JavaScript-Code, dass manche Dinge ohne Skript-Unterstützung nur sehr eingeschränkt funktionieren.

Das Tutorial ist ein Auszug aus der 7. Auflage des Buches von Christian Wenz:

JavaScript und Ajax - Das umfassende Handbuch
Galileo Computing, 853 Seiten, 8. aktualisierte Auflage

Die Veröffentlichung des Kapitels erfolgt mit freundlicher Genehmigung von Galileo Press.

Mehr Informationen zum aktualisierten Fachbuch für Webentwickler gibt es hier: JavaScript und Ajax
 
Alle Kapitel des Buches:
1 Grundlagen
2 JavaScript-Praxis
3 Professionelles JavaScript
4 Web 2.0 und Ajax
5 Kommunikation
6 Serverseitige Programmierung
7 Sicherheit
8 Praxis
9 Anhang
Bilder


 

Kommentare
Achtung: Du kannst den Inhalt erst nach dem Login kommentieren.
Alternative Portrait
-versteckt-(Autor hat Seite verlassen)
  • 11.01.2018 - 15:21

Danke für das Tutorial.

x
×
×