HTMLWorld » JScript.NET » JScript.NET und ASP.NET

JScript.NET: JScript.NET und ASP.NET

von Jan Winkler

ASP .NET ist Microsofts neuste Version von ASP . Wie die Vorgängerversion 6.0, bietet natürlich auch ASP .NET den Zugang zu JScript bzw. hier zu JScript.NET . In diesem Kapitel wird davon ausgegangen, dass Sie mit einigen Grundkenntnissen in Bezug auf ASP vertraut sind. Natürlich kann hier nicht der gesamte Überblick über ASP .NET gegeben werden, deshalb werden wir uns hier auf die Grundinformationen konzentrieren.

Was ist ASP?

ASP ist ganz allgemein eine serverseitige Sprache (oder besser: Sprachanwendung) die es ermöglicht gewöhnliche (HTML-) Dokumente anzupassen und Funktionen auf dem Server auszuführen. Das Akronym steht hier für Active Server Pages. Im Grunde ist ASP vergleichbar mit PHP nur mit dem Unterschied, dass ASP keine Programmiersprache im eigentlichen Sinn ist, sondern lediglich die notwendigen Mittel zur Verfügung stellt. Innerhalb einer ASP-Datei werden dazu bestimmte Skript-Abschnitte in den normalen HML-Code eingefügt. ASP hat hier den Vorteil gegenüber PHP , dass die Skripte entweder in VBScript oder JScript geschrieben werden können.

Man könnte ASP auch mit serverseitigem JavaScript aus Kapitel 1 vergleichen. Wird ein Dokument vom Browser beim Server abgefragt, sucht der Server das Dokument zuerst heraus und ließt es dann. Findet der Server darin die genannten ASP-Skripte, so werden diese ausgeführt. Das Skript selbst kann dann z.B. zusätzliche Informationen in das Dokument schreiben. Der Server setzt die Informationen des Skriptes und der ursprünglichen HTML-Datei dann wieder zusammen und schickt sie an den Browser.

ASP .NET erweitert das ursprüngliche ASP um einiges. Neben den Features, die das .NET-Framework mit seinen unzähligen Klassen mit sich bringt, wird nun auch bei ASP .NET darauf gesetzt, die Anwendung zu kompilieren um schneller ausführbar zu sein. Dazu muss die Anwendung nicht selbständig kompiliert werden - der Server übernimmt dies beim ersten Abruf der Seite. Zudem können nun Webservices und derartige Internet-Anwendungen erstellt werden - und noch eine ganze Reihe mehr.

Voraussetzungen für ASP.NET

Die Voraussetzungen für ASP .NET gehen ein wenig über die des .NET-Frameworks hinaus. Oberste Grundlage ist natürlich ein installiertes und funktionierendes .NET-SDK. Dazu kommt, dass die "Internet Informationsdienste" sowie MDAC 2.7 installiert sein müssen. Im Gegensatz zum .NET-Framework muss allerdings als Betriebssystem mindestens Windows 2000 Server/Advanced Server oder Windows XP Professional verwendet werden - Windows 98 tut es hier nicht.
Ist die Software vorhanden, muss ASP .NET zunächst eingerichtet werden. Deshalb sollte zunächst ein virtuelles Verzeichnis angelegt werden. Dies geschieht indem Sie mit der rechten Maustaste auf das Verzeichnis, das Sie als virtuelles Stammverzeichnis wählen möchten, klicken und "Eigenschaften" wählen. Innerhalb der Registerkarte "Webfreigabe" finden sich zwei Checkboxen wovon zweitere ("Diesen Ordner freigeben") markiert werden sollte. Für das Verzeichnis sollte mindestens ein Alias-Name existieren. Unter diesem Namen ist das Verzeichnis dann auch auf dem Webserver zugänglich. Außerdem braucht ASP .NET für dieses Verzeichnis die Freigabe Skripte laufen lassen zu können ("Anwendungsberechtigungen"). Außerdem kann das Verzeichnis noch innerhalb der Registerkarte "Freigabe" freigeschaltet werden. Sämtliche ASP .NET -Anwendungen können nun innerhalb dieses Verzeichnisses ausgeführt werden.

Alles Zusammen: ASP.NET und JScript.NET

Prinzipiell kann es nun also los gehen zu programmieren und eigene ASP .NET -Anwendungen zu erstellen. Ein ASP .NET -Dokument ist - wie gewohnt - nichts anderes als ein normales ASCII-Textdokument. Prinzipiell kann darin alles vorkommen: HTML, XML ,JavaScript ,VBScript usw. ASP.NET-Dokumente tragen zur Erkennung vom Server die Dateiendung .aspx, was sie von normalen ASP-Dokumenten (Dateiendung .asp) unterscheidet. Innerhalb der Datei sollte als erstes mitgeteilt werden, welche Skriptsprache verwendet wird. Dies geschieht in der Regel mit einem Tag direkt in der ersten Zeile des Dokumentes. Für JScript notiert man:

<%@ Page LANGUAGE="JScript" %>

Danach folgen die zu importierenden Packages. Jedes Package wird mit einem einzelnen Tag importiert. Der entsprechende Tag hat die folgende Syntax:

<%@ import namespace="Namensraum" %>

... wobei an Stelle von Namensraum der Name des Namespaces notiert wird. Sind alle Packages importiert, kann es ans Einfügen des eigentlichen Codes gehen. ASP .NET stellt dazu drei Tags zur Verfügung, innerhalb derer der Code notiert werden kann. Diese können prinzipiell an jeglicher Stelle des Dokumentes untergebracht werden. Sie stören das spätere Design nicht weiter, da sie vom Server entfernt werden. Einzig wichtig für die Wahl der Stelle ist der Zusammenhang mit dem verwendeten Code. Fügt der Code beispielsweise neuen HTML-Code in die Seite ein, sollte dieser Skript-Abschnitt an der Stelle befindlich sein, an der nachher auch der eingefügte HTML-Code zu erwarten ist. Ebenso ist es zumeist sinnvoll globale Funktionen, Variablem und Konstanten (etc.) im oberen Bereich des Quelltextes zu definieren - einfach der Übersicht halber.

Definitionsblöcke

Die Definition von globalen Variablen, Funktionen und Konstanten wird allgemein innerhalb des script-Elements vorgenommen. Dieses sollte von HTML her bereits bekannt sein. Als Wert des language-Attributes erhält es JScript. Zusätzlich muss das Attribut runat mit dem Wert server notiert werden. Es deutet dem Server, dass es sich dabei um vom Server zu verarbeitenden Code handelt. Innerhalb des script-Elements können dann sämtliche Deklarationen vorgenommen werden. Bitte beachten Sie: Der script-Bereich ist nicht zum Ausführen von Code gedacht - tun Sie es doch erhalten Sie einen Syntaxfehler. Beispiel:

Codeblöcke

Da innerhalb des script-Blocks keine Anweisungen direkt aufgerufen werden können, muss dies von anderer Stelle her geschehen. Dazu definiert ASP .NET einen speziellen Tag mit der Syntax ...

<%
... Inhalt ...
%>

Zwischen <% und %> kann nun sämtlicher Code stehen, der ausgeführt werden soll. Hier sind allerdings wiederum keine Klassendefinitionen möglich. Dies bringt zwar den Nachteil, dass bei längeren Dokumenten immer zwischen script-Block und Code-Block hin und her gescrollt werden muss - zugleich ist der Code aber wesentlich "ordentlicher" und aufgeräumter.

Wertblöcke

Ein dritter Typ von Tags ermöglicht die Ausgabe eines Variablenwertes. Der Tag wird ebenso wie der Code-Block notiert. Allerdings folgt hier nach <% ein Gleichheitszeichen. Diese Blöcke können nur einen Ausdruck beinhalten, der anschließend automatisch ausgegeben wird. Beispiel:

Das Beispiel gibt an der betreffenden Stelle den Text "Hallo Welt!" aus.

Ausgabe erzeugen

Anders als bei Konsolenanwendungen von JScript.NET kann bei ASP .NET nicht der print-Aufruf verwendet werden. Für sämtliche Ausgaben die in ein Dokument erfolgen sollen steht das Response-Objekt zur Verfügung. Es definiert Eigenschaften und Methoden, die den Zugriff auf das an den Browser zurück geschickte Dokument (eben den Response) erlauben und wird vom Namespace System.Web.HttpResponse zur Verfügung gestellt. Es braucht innerhalb von ASP .NET nicht extra importiert werden sondern steht immer zur Verfügung. Die Write-Methode ebendieses Objektes erlaubt das Schreiben in ein Dokument. Bitte beachten Sie dabei, dass nicht wirklich in das Dokument geschrieben wird, dass sich auf der Festplatte befindet. Der Server behält eine komplette Kopie des angeforderten Dokuments in seinem Speicher - hier wird geschrieben. Der Browser erhält also nur das Resultat aus dem Serverspeicher. Beispiel:

<%@ Page language="JScript" %>
<script language="JScript" runat="server">
var d:Date = new Date();
var day:String = d.getDate();
var mon:String = d.getMonth();
var yea:String = d.getYear();
</script>
<html>
<body>
<h1>ASP.NET</h1>
<hr>
<p>Heute ist der
<%
Response.Write(day+'.'+mon+'.'+yea);
%>
</p>
<hr>
<p>Willkommen bei ASP.NET!</p>
</body>
</html>

Das Response-Objekt im Einzelnen

Das Response-Objekt gehört zum Namespace System.Web.HttpResponse. Da innerhalb der Objektreferenz im Anhang nicht sämtliche Namespaces, deren Klassen, Eigenschaften und Methoden genannt werden können (das würde den Umfang dieses Tutorials im Wesentlichen übersteigen), soll hier kurz auf die Eigenschaften und Methoden des Response-Objektes eingegangen werden, da dieses eines der wichtigsten im Zusammenhang mit ASP .NET ist.

Eigenschaft	Beschreibung
Buffer	Boolean. Beschreibt, ob der Buffer (interner Speicher) nach vollständiger Verarbeitung der Antwort gesendet werden soll.
Charset	String. Beschreibt den Ausgabezeichensatz des HTTP-Response.
ContentEncoding	Encoding. Entspricht Charset.
ContentType	String. Beschreibt den Mime-Type der Ausgabe.
Cookies	HttpCookieCollection. Ruft die Cookie-Liste ab.
Expires	Int. Beschreibt die Ablaufzeit in Minuten.
ExpiresAbsolute	DateTime. Beschreibt die Ablaufzeit als Datum.
IsClientConnected	Boolean. Beschreibt, ob der Benutzer noch mit dem Server verbunden ist.
Output	TextWriter. Ruft den Ausgabestream als TextWriter-Objekt ab.
Status	String. Legt die Status-Zeile fest.
StatusCode	Int. Legt den Statuscode fest.
StatusDescription	String. Legt die Status-Nachricht fest.

Dazu ein Beispiel:

<%@ Page language="JScript" %>
<%
Response.Expires = 1;
Response.StatusCode = 404;
Response.StatusDescription = 'URL nicht gefunden';
%>

<html>
<head>
<title>404 - URL nicht gefunden</title>
</head>
<body>
<h1>404</h1><h2>URL nicht gefunden</h2><hr>
<p>Die von Ihnen angeforderte Datei existiert
nicht mehr oder konnte nicht gefunden werden.</p>
</body>
</html>

Der Server liefert darauf hin das folgende Resultat:

HTTP/1.1 404 URL nicht gefunden
Server: Microsoft-IIS/5.0
Date: Mon, 02 Dec 2002 21:04:14 GMT
Cache-Control: private
Expires: Mon, 02 Dec 2002 21:05:14 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 402

<html>
<head>
<title>404 - URL nicht gefunden</title>
</head>
<body> ... </body>
</html>

Das Response-Objekt besitzt unter anderem die folgenden Methoden:

Methode	Beschreibung
AddHeader	String, String. Fügt einen HTTP-Header an die Antwort an. Header-Name und -Wert werden erwartet.
BinaryWrite	Byte. Schreibt die übergebenen Binärdaten in die Antwort.
Clear	Löscht alle Inhalte aus dem Ausgabepuffer.
Close	Schließt die Verbindung zum Benutzer.
End	Sendet alle gepufferten Daten an den Benutzer und beendet die Seite.
Flush	Sendet alle gepufferten Daten an den Benutzer.
Redirect	String [, Boolean]. Leitet den Benutzer zu einer anderen Seite weiter. Es wird der Pfad der neuen Seite sowie optional ein Boolean erwartet, ob die Ausführung der Seite beendet werden soll.
Write	String. Schreibt einen String in die Ausgabe.
WriteFile	String [, Boolean]. Schreibt eine Datei in die Ausgabe. Wird der zweite Parameter mit true beschrieben, so erfolgt die Ausgabe der Datei in den Speicherblock.

Ein Beispiel dazu:

<%@ Page language="JScript" %>
<html>
<body>
<%
Response.Write('Sie werden nun vom Server getrennt!');
Response.Flush();
Response.Close();
Response.Write('Diesen Text sollten Sie schon nicht mehr '+
'sehen!');
%>
</body>
</html>

Das Request-Objekt im Einzelnen

Neben dem, was an den Benutzer zurück geschickt wird, ist natürlich auch das interessant, was der Benutzer bzw. sein Browser geschickt hat. Hierzu dient das Request-Objekt. Es ist im gleichen Namespace wie das Response-Objekt enthalten und liefert jede Menge Informationen über die Anfrage des Benutzers. Auch hier sollen kurz die wichtigsten Eigenschaften und Methoden aufgelistet werden um einen kurzen Einblick zu gewährleisten.

Eigenschaft	Beschreibung
ApplicationPath	String. Beschreibt den virtuellen Pfad der ausgeführten Anwendung. Z.B. /abc
Browser	HttpBrowserCapabilities. Ruft die Browserinformationen des Benutzers ab.
Cookies	HttpCookieCollection. Ruft die übergebenen Cookies ab.
FilePath	String. Beschreibt den virtuellen Pfad der abgerufenen Datei. Z.B. /abc/def.aspx
Files	HttpFileCollection. Ruft die übergebenen Dateien ab.
Form	NameValueCollection. Ruft die übergebenen Formularwerte ab.
HttpMethod	String. Beschreibt die HTTP-Abrufmethode.
Path	String. Beschreibt den Pfad der abgerufenden Datei. Z.B. /abc/def.aspx
PhysicalPath	String. Beschreibt den physischen Pfad der Abgerufenden Datei. Z.B. c:\root\abc.aspx.
QueryString	NameValueCollection. Ruft die übergebenen Suchparameter ab.
ServerVariables	NameValueCollection. Ruft die Servervariablen ab.
URLReferrer	Uri. Ruft die Herkunftsadresse ab.
UserAgent	String. Gibt die Browserinformationen des Benutzers (unformatiert) aus.
UserHostName	String. Gibt den Host-Namen des Benutzers aus.
UserLanguages	String. Gibt die Sprachbeschreibung des Benutzers aus (z.B. de, fr, en).

Ein Beispiel zur Unterscheidung von ApplicationPath, FilePath, Path und PhysicalPath:

with(Request)
{
  Response.Write(
   'ApplicationPath: '+ApplicationPath+'<br>'+
   'FilePath: '+FilePath+'<br>'+
   'Path: '+Path+'<br>'+
   'PhysicalPath: '+PhysicalPath+'<br>'
  )
}

... und so können Formularwerte ermittelt werden:

<%@ Page language="JScript" debug="true"%>
<html>
<body>
<%
  var s:String = '';
  var i:int;
  var f:NameValueCollection = Request.Form;

  for(i=0; i<f.Count; i++)
  { s += f.GetKey(i)+': '+f.Get(i)+'<br>'; }
  Response.Write('<p>'+s+'</p>');
%>
<hr>
<form action="<%=Request.Path%>" method="POST">
Name: <input type="text" name="name"><br>
Mail: <input type="text" name="mail"><br>
URL: <input type="text" name="url"><br>
<input type="submit"> <input type="reset">
</form>
</body>
</html>

Das Request-Objekt besitzt unter anderem die folgenden Methoden:

Methode	Beschreibung
BinaryRead	Int. Liest die angegebene Zahl an Binärdaten ein und gibt diese als Array aus Bytes aus.
SaveAs	String, Boolean. Speichert den Abruf in der übergebenen Datei. Der zweite Parameter bestimmt ob die Kopfdaten mit gespeichert werden sollen.

ASP.NET-Webforms

Anders als bei früheren ASP-Versionen, sind in ASP .NET nun neue ASP .NET -Tags enthalten - die Webforms. Das sind Tags vergleichbar mit HTML-Tags die eine bestimmte Komponente darstellen. Das Prinzip ist folgendes:

Der Programmierer erstellt wie gewohnt eine Seite und kann in diese die einzelnen Elemente der Webforms einbauen. Ruf ein Benutzer eine Seite ab, in der Webforms enthalten sind, so stellt der Server diese Elemente automatisch in den für den Anwender am besten zu benutzenden HTML-Code um. Der Benutzer erhält das für ihn am besten nutzbare Resultat und der Programmierer spart an Aufwand um die Seite an die verschiedenen Browser und -versionen anzupassen. ASP .NET definiert folgende Tags zur Verwendung als Webforms-Komponente:

- asp:AdRotator
- asp:Button
- asp:Calendar
- asp:CheckBox
- asp:CompareValidator
- asp:CustomValidator
- asp:DataGrid
- asp:DataList
- asp:DropDownList
- asp:Image
- asp:ImageButton
- asp:Label
- asp:LinkButton
- asp:ListBox
- asp:Literal
- asp:Panel
- asp:PlaceHolder
- asp:RadioButton
- asp:RadioButtonList
- asp:RangeValidator
- asp:RegularExpressionValidator
- asp:RequiredFieldValidator
- asp:Table
- asp:TextBox
- Asp:ValidationSummary
- asp:Xml

Die Tags entsprechen in etwa den normalen HTML-Tags (z.B. button, textbox oder table) und besitzen je spezifische Attribute, die die Anpassung der Komponenten erlauben. Jede Komponente wird als einzelner XML-Tag notiert (also mit /> am Ende sofern kein Inhalt enthalten ist) und sollte mit einer ID (id-Attribut) versehen werden. Innerhalb eines (serverseitigen) Skriptes kann dann über diese ID auf das Element zugegriffen werden. Ein Beispiel:

<%@ Page language="JScript" %>
<html>
<head>
<script language="JScript" runat=server>
  function SagAn(o : Object, e : EventArgs)
{
  Ausgabe.Text = Eingabe.Text;
}
</script>
</head>
<body>
<form runat="server">
  <asp:Textbox id="Eingabe" Text="Gib was ein!" runat="server"/>
  <asp:Textbox id="Ausgabe" Text="" runat="server"/>
  <asp:button id="Knopf" runat="server" Text="Sag an!"
   onclick="SagAn"/>
</form>
</body>
</html>

Beim Browser landet folgendes Resultat:

Wie man hier sieht, wurden sämtliche Tags mit dem Attribut runat="server" umgestellt bzw. entfernt. Der Server hat das Formular automatisch angepaßt und versteckte Felder eingefügt. Wird auf den Button geklickt, weiß der Server, um welche Elemente es sich gehandelt hat und hat außerdem ja noch den Code der Funktion SagAn im "Hinterkopf". Wird nun also das Formular abgeschickt, weiß der Server, dass die Funktion SagAn auszuführen ist und verfährt dementsprechend. Hier wird der Text des Ausgabefeldes durch den Text des Eingabefeldes ersetzt.

Bitte beachten Sie: Wie der Name "Webforms" schon sagt, handelt es sich dabei um Formularsteuerelemente. Ebenso können die meisten dieser Elemente auch nur innerhalb eines serverseitigen Formulars (form-Element mit dem Attribut runat="server") eingesetzt werden - andernfalls erscheint eine Fehlermeldung.

Ereignisse bei Webforms

Wie an obigem Beispiel schon erkennbar ist, kann bei Webforms ebenso wie bei normalen Formularen mit Ereignissen gearbeitet werden. Jedes ASP .NET -Element besitzt dazu eine Reihe von Events die verwendet werden können. Die Ereignisnamen entsprechen in etwa denen, die von JavaScript her bekannt sind. Allerdings sollten Sie bedenken, dass clienseitige Ereignisse wie z.B. onmouseover oder onkeypress nicht unterstützt werden - einfach aus dem Grund, dass der Server diese natürlich nicht abfangen kann. Wie Sie es gewohnt sind, können Sie auch bei Webforms die Ereignisse mit einer Funktion beliebigen Namens belegen. Einziger Unterschied: Innerhalb der Ereignisdefinition im Tag dürfen keine Klammern oder Parameter notiert werden - hier steht lediglich der Funktionsname der aufzurufenden Funktion. Der Funktion werden automatisch zwei Parameter übergeben: Ein Object- und EventArgs-Objekt. Beide müssen unbedingt in der Funktionsdefinition enthalten sein. Der erste Parameter repräsentiert das Objekt, das das Ereignis ausgelöst hat (z.B. der Button auf den geklickt wurde). Der zweite Parameter ist eine Art Array der Ereignisparameter. Neben den Ereignissen der einzelnen Komponenten steht das systeminterne Page_Load-Ereignis zur Verfügung. Es wird automatisch aufgerufen, sobald eine Datei verarbeitet wird. Um darauf reagieren zu können muss lediglich eine Funktion mit diesem Namen erstellt werden. Beispiel:

function Page_Load(o : Object, e : EventArgs)
{
Eingabe.Text = 'Beim Laden der Seite ausgeführter Code ...';
}

CodeBehind

Ein wichtiger Bestandteil der Webforms sind die sogenannten CodeBehind-Dateien. Prinzipiell besteht ein Webform aus zwei Teilen: Einer anzuzeigenden Seite und einer CodeBehind-Datei. Diese CodeBehind-Datei ist nichts anderes als eine ( JScript.NET-) Datei die an das entsprechende Dokument gekoppelt wird. Diese Dateien tragen den gleichen Dateinamen wie das Dokument an das sie gekoppelt sind und werden lediglich durch einen zusätzlichen Suffix erweitert. Heißt beispielsweise das anzuzeigende Dokument meineseite.aspx so heißt die entsprechende CodeBehind-Datei meineseite.aspx.js (sofern JScript.NET als Skriptsprache verwendet wird). Wird Visual Basic.NET verwendet lautet die Dateiendung .vb und bei C# (C-Sharp) eben .cs. Der Vorteil dieser Dateien liegt auf der Hand: Bessere Übersicht, Anpassbarkeit und Wiederverwendbarkeit des Codes.
Bei der CodeBehind-Datei handelt es sich um eine normale JScript.NET-Datei. Diese muss als DLL kompiliert werden und wird dann in die statische Seite eingebunden. Da es sich um eine DLL handelt, müssen sämtliche Funktionen (etc.) innerhalb eines Packages und Klassen verpackt werden. Beispiel:

import System
package Beispiel
{
class Klasse extends System.Web.UI.Page
{
  var Ausgabe:System.Web.UI.WebControls.TextBox;
  var Eingabe:System.Web.UI.WebControls.TextBox;

  function SagAn(o : Object, e : EventArgs)
  { Ausgabe.Text = Eingabe.Text; }

  function Page_Load(o : Object, e : EventArgs) : void
  { Eingabe.Text = 'Gib was ein!'; }
}
}

Um die CodeBehind-Datei nun in unser Dokument einzugliedern, wird der uns schon bekannte @Page-Tag verwendet (<%@ Page ... %>). Um auf die Datei zu verweisen benutzen wir das src-Attribut, dem wir den Pfad der .js-Datei als Wert übergeben. Außerdem muss das zu verwendende Package benannt werden. Dies wird mit dem inherits-Attribut getan, als dessen Wert wird das Package und die Klasse definieren. Die Zeile sieht entsprechend so aus:

<%@ Page language="JScript" src="webforms1.aspx.js"
inherits="Beispiel.Klasse"%>

Der Server sucht nun beim Abruf der Seite nach dem zu implementierenden Package Beispiel und der entsprechenden Klasse Klasse. Als Quelldatei haben wir hier webforms1.aspx.js angegeben. Dementsprechend wird nach einer Datei webforms1.dll gesucht. Dazu ist zu sagen, dass der Server alle DLL-Dateien immer im Unterverzeichnis bin vermutet und dementsprechend auch nur dort sucht. Befinden sich also die Dateien webforms1.aspx und webforms1.aspx.js im Verzeichnis /Beispiel/*.* so wird nach der DLL im Verzeichnis /Beispiel/bin/*.* gesucht. Kann der Server diese Datei nicht finden, wird Sie automatisch aus der im src-Attribut definierten Datei kompiliert. Beispiel der dazugehörigen ASP X-Datei (webforms1.aspx):

<%@ Page language="JScript" src="webforms1.aspx.js"
         inherits="Beispiel.Klasse"%>
<html>
<head></head>
<body>
<form runat="server">
<asp:Textbox id="Eingabe" Text="Gib was ein!" runat="server"/>
<asp:Textbox id="Ausgabe" Text="" runat="server"/>
<asp:button id="Knopf" runat="server" Text="Sag an!"
             onclick="SagAn"/>
</form>
</body>
</html>

Nun wird auch langsam klar, warum wir innerhalb der CodeBehind-Datei eine Klasse des Typs System.Web.UI.Page erstellt haben: Der Server wendet diese Klasse auf das gesamte Dokument an. Bedeutet also im Klartext, dass das gesamte Dokument innerhalb dieser Klasse repräsentiert werden muss. Ebenso muss auch eine Eigenschaft für jede Webforms-Komponente die angesprochen werden soll erstellt werden. Hierbei kommt wiederum das id-Attribut zum Tragen: Der Server setzt die Eigenschaften der verwendeten Klasse mit den Elementen des Dokumentes gleich. Die Eigenschaften müssen dazu den gleichen Namen wie die ID des Elements tragen. Zudem muss natürlich auch der gleiche Typ vorliegen.

« zurück

weiter »

Bewerten

Aus dem JScript.NET Forum ...

JScript.net und SQL von Raydir

zum JScript.NET Forum »