Clientseitiger Code in ASP.NET-Seiten

Während das vorherige Beispiel die grundlegende Verwendung der einzelnen Elemente demonstrierte, kann es Situationen geben, wo ein bestimmter Ansatz erforderlich ist, um die gewünschte Funktionalität zu erzielen. Ein gutes Beispiel hierfür ist eine Anwendung, welche bestimmte Buttons innerhalb eines Repeater-Steuerelements anzeigt, und zwar in Abhängigkeit von der Art des angemeldeten Besuchers. Ein weiterer zu berücksichtigender Aspekt dieser Anwendung war die Verwendung von Javascript und DHTML zur Präsentation einer Benutzeroberfläche mit drei Registerkarten, die alle separate Repeater-Steuerelemente enthielten. Ein Klick auf eine dieser Registerkarten sollte die beiden anderen Registerkarten verbergen und das Repeater-Steuerelement für die ausgewählte Registerkarte anzeigen.

Jede Reihe der Repeater-Steuerelemente enthielt einen „Bearbeiten“-Button, der nur angezeigt werden sollte, wenn eine bestimmte Art von Benutzer angemeldet war. Ursprünglich sollte diese Funktionalität mit Hilfe des ItemCreated-Ereignisses des Repeater-Steuerelements realisiert werden. Dies funktionierte zwar beim erstmaligen Laden der Seite, aber beim Auswählen unterschiedlicher Registerkarten gingen alle zugehörigen Formatierungen verloren. Das heißt, das ItemCreated-Ereignis wurde nur ausgelöst, wenn die Seite das erste Mal geladen oder mit Daten-Steuerelementen gefüllt wurde, nicht aber, wenn clientseitig Javascript oder DHTML ausgeführt wurden. Jedes Mal, wenn Javascript oder DHTML ausgeführt wurden, gingen alle über das ItemCreated-Ereignis erstellten Formatierungen verloren. Die Lösung bestand in der Verwendung von clientseitigem Inline-Code zur Kontrolle des Anzeigeverhaltens der Elemente. Es dürfte noch andere Situationen geben, wo erst die Kombination von Elementen den gewünschten Effekt bringt.

Optionen für Entwickler

Eine ASP.NET-Seite enthält viele Elemente, welche dem Entwickler eine Vielzahl von Optionen für eine bestimmte Aufgabe bieten. So kann man eine gemeinsame Fußzeile auf allen Seiten per SSI (Server-Side Include) realisieren oder ein eigenes Steuerelement entwickeln. Außerdem kann man den Quellcode in eine separate Code Behind-Datei auslagern oder innerhalb der ASP.NET-Seite Codedeklarationsblöcke einfügen oder sogar Inline-Code benutzen. Manches an diesen Elementen erinnert vielleicht an die ASO-Klassen-Programmierung, aber sie haben sich doch deutlich verändert. Letztlich muss jedes Entwicklungsteam im Einzelfall entscheiden, welcher Ansatz für eine bestimmte Anwendung benutzt werden soll.