Online-Artikel Drucken: Webentwicklung mit Delphi 2005

Während Delphi 8 nur noch ASP.NET WebForms unterstützt hat, stellt Delphi 2005 den Entwickler zunächst vor die Qual der Wahl. Für die native Entwicklung sind nach wie vor die inzwischen etwas angegrauten WebSnap- und Pageproducer-Komponenten enthalten. Die mit Delphi 7 eingeführten IntraWeb-Komponenten sind sogar in mehreren Versionen Bestandteil von Delphi 2005. Enthalten sind die IntraWeb-Komponenten sowohl für native Win32 als auch für VCL.NET, sodass die Möglichkeit besteht, bestehende IntraWeb-Projekte nach Delphi 2005 zu übernehmen.

ASP.NET und IntraWeb
Mit der Webentwicklung mithilfe der klassischen Pageproducer-Komponenten, die ja im Endeffekt nicht anderes taten, als Webrequests in Parameter für Ereignishandler umzuwandeln, hat ASP.NET noch am wenigsten zu tun. Zumindest vom Konzept ähnelt ASP.NET hier am ehesten den IntraWeb-Komponenten. Bei beiden Frameworks lassen sich Webformulare in der IDE mithilfe von Komponenten gestalten. Im Falle von ASP.NET kommen dazu die Komponenten aus den Namespaces System.Web.UI.WebControls und System.Web.UI.HtmlControls in Frage, während bei IntraWeb die speziellen IntraWeb-Controls statt normaler visueller VCL-Komponenten verwendet werden. Bei beiden Frameworks lassen sich Ereignishandler dieser Komponenten zudem fast so programmieren als liefe der Code wirklich im Webclient, was de facto weder bei ASP.NET noch bei IntraWeb der Fall ist.

Bei beiden Frameworks läuft ein Serverprozess, der den Status eines Webclients verwaltet und die verwendeten Controls und zugeordneten Handler in das notwendige HTML und Javascript für die Darstellung rendert. Beim Server-Prozess enden allerdings die Parallelen. Bei IntraWeb hat der Entwickler die freie Auswahl, ob er eine Isapi- oder Apache-DLL oder sogar eine alleinstehende EXE-Datei, die den Webserver gleich enthält, erzeugen möchte. Bei ASP.NET sind Sie auf einen existierenden Webserver angewiesen, der .Net unterstützt, was zwar in der Regel auf den Internet Information Server von Microsoft hinausläuft, aber nicht zwangsweise muss. Eine kleine Alternative ist der Cassini-Webserver, ein in .Net geschriebener Webserver, dessen Sourcecode Sie im Demos-Verzeichnis von Delphi finden.

Während Sie sich bei IntraWeb zunächst gar nicht um HTML kümmern (zumindest solange nicht, wie die Template-Prozessor-Komponenten verwenden) und die Komponenten wie bei normalen Formularen platzieren und ausrichten, bleiben Sie bei ASP.NET immer auf Tuchfühlung mit den Einschränkungen, die HTML mit sich bringt.

ASP.NET Basics
Im einfachsten Fall können Sie ASP.NET-Anwendungen mit Notepad erstellen, indem Sie im HTML-Quellcode die ASP.NET-Serversteuerlemente verwenden und durch den Prefix asp: kennzeichnen. Daneben ist es wichtig das HTML-Formular mit dem Attribut runat=server zu kennzeichnen.
Im Listing 1 sehen Sie einen einfachen Rechner mit ASP.NET.

Listing 1

<html>

<body>

<form runat="server">

<asp:TextBox ID="op1" RunAt="server" />

+

<asp:TextBox ID="op2" RunAt="server" />

<asp:Button Text="  =  " OnClick="OnAdd" RunAt="server" />

<asp:Label ID="Sum" RunAt="server" />

</form>

</body>

</html>

<script language="C#" runat="server">

void OnAdd (Object sender, EventArgs e)

{

int a = Convert.ToInt32 (op1.Text);

int b = Convert.ToInt32 (op2.Text);

Sum.Text = (a + b).ToString ();

}

</script>

Wird eine solche Datei von Webserver bzw. dem .Net Framework beim Abruf einer ASPX-Seite verarbeitet, erzeugt ASP.NET zunächst eine temporäre Datei, die eine von System.Web.UI.Page abgeleitete Klasse enthält und kopiert den SKriptcode der ASPX-Datei mit etwas eigenem Code in die von Page abgeleitete Klasse. Die Methoden wie OnAdd im <script>-Block einer ASPX-Datei werden zu Membermethoden der abgeleiteten Klasse. Diese On-The-Fly erzeugte Klasse wird kompiliert und in einem Systemordner abgelegt, sodass bei erneuten Seitenaufrufen die zwischengespeicherte DLL verwendet werden kann. Letztendlich wird von ASP.NET diese erzeugte Klasse instanziiert und ausgeführt. Dabei instanziiert das Page-Objekt alle Steuerelemente, die in ihm deklariert sind, und spricht deren Ausgaben an.

Auch wenn es theoretisch möglich, auf diese Art und Weise ASP.NET-Anwendungen zu schreiben, ist dieser Weg doch unüblich, zumal er einen der wesentlichen Vorteile die ASP.NET gegenüber dem alten ASP hat, die mögliche Trennung von Logik und HTML, verschenkt.

Code-Behind
Die Trennung von Logik und Code wird möglich durch die so genannte Code-Behind-Technologie, die quasi alle ASP.NET IDEs verwenden. Die Entwicklungsumgebungen gehen dabei im Endeffekt ähnlich vor, wie ASP.NET zur Laufzeit bei obigem Programm. Im Editor stehen die aspx-Seite und eine zugehörige Quelltextdatei mit einem Nachfahren von System.Web.UI.Page als separate Dateien zur Verfügung. Auch hier entsprechen die serverseitigen Controls-Feldern in der Klasse und ihre Ereignishandler entsprechen Methoden der Klasse. Wenn Sie eine ASP.NET-Anwendung in Delphi erstellen, erhalten Sie neben der ASPX-Datei WebForm1.Aspx eine korrespondierende Quelltextdatei WebForm1.pas.

Start in Delphi
Wenn Sie eine neue Webanwendung erzeugen, werden Sie in einem Dialog zunächst nach dem Speicherort der Anwendung gefragt. Daneben legen Sie in dem Dialog auch das virtuelle Verzeichnis auf dem IIS fest, unter dem die Applikation gespeichert werden soll. Wenn Sie die Anwendung nachträglich verschieben, sollten Sie nicht vergessen, auch das virtuelle Verzeichnis im IIS auf den neuen Pfad umzustellen (Start | Systemsteuerung | Verwaltung | Internetdienste-Manager). Wenn Sie als Vorgabe nicht den IIS oder ein anderes Verzeichnis verwenden möchten, lässt sich dies über die Voreinstellungen in Delphi (Tools | Optionen | ASP.NET) ändern.

Abb. 1: Startdialog einer ASP.NET-Anwendung
Sobald Sie den Dialog bestätigt haben, sehen Sie Ihre erste ASP.NET-Seite im Designmodus in der IDE (siehe Abb. 2). Bevor Sie jetzt Komponenten platzieren, sollten Sie sich überlegen, welches Layout Sie für Ihre Seite verwenden wollen. Prinzipiell stehen Ihnen das Flowlayout und das GridLayout zur Verfügung. Das GridLayout (XY Layout) erlaubt die absolute Positionierung von Komponenten und gestattet leichte Kontrolle über das Layout, kann aber bei Clients mit anderen Auflösungen kritisch werden. Im Flowlayout werden die Controls und Texte einfach hintereinander gehängt. Um hier zu positionieren, können bzw. müssen Sie HTML-Tabellen verwenden. Was prinzipiell auch in der IDE von Delphi möglich ist ( Menü Tabelle | Einfügen ). Welches Layout Sie haben möchten stellen Sie im Dokument ein, dass Sie zunächst im Objektinspektor auswählen müssen (siehe Abb. 2).

Abb. 2: Das Layout schalten Sie im Dokument um

Als visuelle Controls stehen Ihnen im Framework Komponenten auf der Palettenseite WebControls (Namespace System.Web.UI.WebControls) und HtmlControls (Namespace System.Web.UI.HtmlControls) zur Verfügung. Der Hauptunterschied zwischen beiden ist, dass die WebControls Serversteuerelemente erzeugen, die im HTML-Code über den Prefix asp: gekennzeichnet sind, während die HtmlControls lediglich die normalen HTMLTags mit dem Zusatz runat=server erzeugen. Leistungsfähiger sind in jedem Fall die Webcontrols, während die HtmlControls die Integration bestehender Formular erleichtern.

ASP.NET Controls

// System.Web.UI.WebControls.Button

<asp:Button id="Button1" runat="server" text="Addieren"></asp:Button>

// System.Web.UI.HTMLControls.Button

<input type="button" value="Button">

Neben den visuellen Controls des Frameworks stellt Delphi zusätzliche Komponenten des Component Studio One zur Verfügung sowie eigene datenbanksensitive Controls auf der Seite Db Web. Neben den visuellen Controls können außerdem fast alle nichtvisuellen Komponenten des Frameworks in Webanwendungen verwendet.

Ein Webrechner
Um einen ähnlichen Rechner zu programmieren, wie im eingehenden ASP.NET-C#-Beispiel, platzieren Sie drei Textboxen und einen Button von der Palettenseite WebControls auf dem Formular und garnieren das Formular gegebenenfalls mit etwas HTML-Text, den Sie im Übrigen auch direkt im Designer eintippen können. Die Eigenschaften der Controls lassen sich genauso einfach im Objektinspektor setzen, wie dies bei IntraWeb-Komponenten der Fall ist. Um die Inhalte beider Editierfelder zu addieren und im dritten ausgeben, benötigen Sie noch eine Ereignishandler für den Klick des Buttons. Wie bei normalen Anwendungen erzeugen Sie diesen entweder über die Ereignisseite im Objektinspektor oder durch Doppelklick auf den Button im Designer. Wenn Sie die Auslieferung zusätzlicher VCL-Assemblies vermeiden wollen, sollten Sie statt der gewohnten Funktionen aus SysUtils.pas (IntToStr, StrToInt) lieber die Convert-Klasse des Frameworks verwenden.

procedure TWebForm1.Button1_Click

(sender: System.Object;

e: System.EventArgs);

var

a,b,c : Integer;

begin

a := Convert.ToInt32 (TextBox1.Text);

b := Convert.ToInt32 (TextBox2.Text);

c := a + b;

TextBox3.Text := c.ToString();

end;

Den Minimalrechner können Sie jetzt das erste Mal testen und aus der IDE heraus starten. Beim ersten Start einer ASP.NET-Anwendung aus Delphi heraus ist es wahrscheinlich, dass der Debugger zunächst einen Timeout meldet, weil ihm die Zeit zum Starten der Anwendung zu lang. In diesem Fall starten Sie die Anwendung einfach erneut. Wenn der IIS installiert ist und läuft (siehe auch Kasten IIS für .Net einrichten), sollte das Ergebnis in etwa so wie in Abbildung 3 aussehen.

Abb. 3: Der Minimalrechner im IE
Um den Code im Debugger mitzuverfolgen können Sie ohne weiteres Breakpoints im Event Handler setzen und die Variablen untersuchen. Wenn Sie die Anwendung testen, achten Sie bitte auf den Ladebalken des IE. Sobald Sie den Button klicken, sendet der Client einen so genannten Postback zum Server und stellt die Seite neu dar. Auf der Serverseite erfolgt dann die eigentliche Verarbeitung des Ereignis-Handlers, die dazu führt, dass das Ergebnis im Client neu dargestellt wird.

Fehler sind in den Controls bisher allerdings noch nicht abgefangen, sodass der Versuch, leere Strings zu addieren, fehlschlägt und im Browser (Abbildung 4) angezeigt wird.

Abb. 4: Fehleranzeige im Explorer
Diese detaillierte Anzeige ist bzw. sollte üblicherweise nur auf Entwicklungsrechnern zu sehen sein. Bevor wir uns Komponenten anschauen, welche diese Fehleingaben auffangen können, möchte ich Ihnen zunächst die Datei genauer vorstellen, die diese Fehleranzeige neben anderen Einstellungen steuert.

Konfiguration von ASP.NET-Anwendungen
Wenn Sie sich den Projektmanager mit Ihrer ASP.NET-Anwendung genauer anschauen, stellen Sie fest, dass neben der WebForm1.aspx und WebForm1.pas bereits weitere Dateien enthalten sind, obwohl Sie diese nicht zugefügt haben. So wie das .Net Framework für Windowsanwendungen Konfigurationsdateien mit dem Namen <Anwendungsname>.Config vorsieht, legt es auch die Datei Web.Config als Standardkonfigurationsdatei für ASP.NET-Anwendungen fest. Neben der Art und Weise wie Fehlermeldungen angezeigt werden (Element CustomErrors), steuert die Datei Web.Config vielfältige Einstellungen für ASP.NET. Es sind dies unter anderem Einstellungen für die Sicherheit und Authentifizierung von Webseiten, wie auch Einstellungen für das Debugging und Tracing von Webanwendungen. Um einen Eindruck von den Möglichkeiten zu erhalten, schalten Sie probehalber die Attribute enabled und pageoutput des Elements trace auf true.

<trace

enabled="true"

requestLimit="10"

pageOutput="true"

traceMode="SortByTime"

localOnly="true"

/>

Die Ausgabe Ihrer Webanwendung sollte dann wie in Abbildung 5 aussehen. Wenn Sie das Gridlayout verwenden, schiebt sich die Traceausgabe allerdings unter Ihre Seite. In diesem Falle ist es sinnvoller, die Ausgabe in eine externe Seite erfolgen zu lassen und pageoutput auf false zu belassen. Die Traceinformationen können Sie in diesem Fall über die Seite trace.axd im Root-Verzeichnis der Webanwendung öffnen.

Abb. 5: Ausschnitt der Trac-Ausgabe im Explorer

Sessionmanagment
Neben den oben genannten Einstellungen steuert die Web.Config-Datei auch das Sessionmanagment der Anwendung. Damit der Serverprozess den Request eines Clients einer Sitzung zuordnen kann, muss das Framework die ID des Clients in irgendeiner Form speichern. ASP.NET verwendet dafür standardmäßig Cookies, während IntraWeb als Vorgabe eine so genannte FatURL verwendet. Um dies Verhalten in IntraWeb zu ändern, markieren Sie lediglich den Servercontroller der Anwendung und stellen die Eigenschaft SessionTrackingMethod auf tmCookie oder tmHidden. Letztgenannte Einstellung verwendet versteckte Felder um die ID zu speichern. In ASP.NET ändern Sie stattdessen vergleichsweise unbequem in der Web.Config-Datei das Attribut cookieless des Elements sessionState. Setzen Sie cookieless auf true, verwendet ASP.NET Fat URLs, um sich die ID eines Clients zu merken. Versteckte Felder können zumindest nicht für die Session-ID verwendet werden. Obwohl die Web.Config Datei zunächst unbequemer erscheint, bietet sie aber dennoch einen Vorteil. Zum einen ist sie ohne Rekompilierung der Anwendung änderbar und zum anderen ist dieser Mechanismus etwas flexibler. In komplexeren ASP.NET-Anwendungen können diese Konfigurationsdateien in mehreren Verzeichnissen vorkommen und so gezielt auf nur auf Teile der Anwendung angewendet werden. Sind Attribute in den Unterverzeichnissen nicht geändert, gelten automatisch die Attribute des übergeordneten Verzeichnisses. Oberhalb aller Web.Config-Dateien einer Anwendung steht zudem noch die Machine.Config-Datei, die sich im Pfad <windir>\Microsoft .Net \Framework\ v1.1.4322\Config findet und die Vorgaben für einen Rechner steuert. Auch wenn Sie hier zunächst nichts ändern wollen, ist die Datei einen Blick Wert, um einen Überblick über die möglichen Konfigurationsoptionen zu bekommen, die glücklicherweise auch direkt in der Datei kommentiert sind.

Validierung von Eingaben
Nach diesem kleinen Ausflug in die Konfigurationsdateien wenden wir uns noch einmal der Validierung von Eingaben zu. Sicher könnte man die Exception vermeiden, indem der Code im Klickereignis des Buttons mit einem Exceptionhandler geschützt wird und im Fehlerfall eine Meldung ausgegeben wird. Allerdings wäre diese Prüfung mit einem Postback verbunden. Um Exceptions gleich bei der Eingabe abzufangen, stellt ASP.NET Validierungscontrols zur Verfügung, die für einfache Validierungen entsprechenden Javascript-Code für den Client erzeugen und die Eingaben ohne Senden von Daten prüfen. Für das Beispielprogramm kommen hier beispielsweise der RequiredFieldValidator oder der RangeValidator in Frage. Ersterer prüft lediglich, ob ein Wert vorhanden ist, während der RangeValidator auf einen Wertebereich prüft. Bei den Validierungscontrols geben Sie in der Eigenschaft ControlToValidate das Control an, das geprüft werden soll. Ist die Validierung nicht erfolgreich, wird der Text der Eigenschaft ErrorMessage dort eingeblendet, wo der Validator platziert ist. Wenn Sie mehrere Validatoren verwenden, sollten Sie zudem die Eigenschaft Display auf den Wert Dynamic stellen, da sonst der Validator den für seine ErrorMessage notwendigen Platz auch dann reserviert, wenn der Text nicht angezeigt wird. Beim RangeValidator sollten Sie zusätzlich auf die Eigenschaft Type achten mit der Sie den Datentyp einstellen können. Steht der Typ auf string (Vorgabe) wird der Validator bei eingestellten Minimal- und Maximalwerten wahrscheinlich in den seltensten Fällen, das von Ihnen gewünschte Ergebnis liefern.

Ausblick
Im zweiten Teil des Artikels im nächsten Entwickler lesen Sie, wie Sie Datenbanken in WebForms verwenden, wo .Net dann doch noch Hidden Fields verwendet und wie Sie sich Daten sessionspezifisch merken können.