In meinem letzten Artikel UserControls mit Properties/Konstruktoren dynamisch laden (Server und Client) habe ich dargestellt, mit welch relativ geringem Aufwand man komplexe ASP.NET-Steuerelemente auch per Javascript über einen WebService in eine Seite injizieren kann. Es geht aber noch besser...

Das Update

Mein Javascript-Code ist, für die mehrmalige Verwendung innerhalb eines Projekts, schon ein ziemlicher Brocken (20-30 Zeilen, ja nachdem wie leserlich man es haben möchte) und so drängt sich ein Refactoring quasi schon auf. Grund dafür ist natürlich der recht umfangreiche AJAX-Aufruf mittels jQuery.

Zudem fiel mir auf, dass ich einen inhaltlichen Fehler begangen habe. In der Javascript-Methode getElementHtml wird im Erfolgfall das Element direkt an den Container gehängt, was man bei dem gewählten Methodennamen nicht direkt erwarten würde. Shame on me...

Um nun die Routine zu entzerren und allgemeingültiger zu halten, habe ich ihr zwei weitere Eingabeargumente namens successFunction und errorFunction verpasst, die definieren was im Erfolgs- bzw. Fehlerfall passieren soll.

UserControls sind herrlich, um Code-Redundanzen zu vermeiden. Wiederkehrenden HTML-Code lagert man in ein solches Benutzersteuelement aus und etwaige Änderungen müssen nur einmal an zentraler Stelle vorgenommen werden.

Programmatisch ein solches Steuerelement in die zu rendernde Seite einzufügen, ist hingegen nicht ganz so trivial. Vor allem, wenn man dem Control eine oder mehrere Eigenschaften verpasst hat, die den Inhalt oder das Aussehen steuern, oder wenn man gar einen Konstrukor mit Argumenten geschrieben hat. Aber ... wie immer gibt es einen Weg, bzw. mehrere, die ich hier aufzeigen möchte.

Ich habe mich nun schon das zweite Mal von ASP.NET hereinlegen lassen und meine Zeit damit vergeudet ein und demselben "Phänomen" auf die Spur zu kommen, daß es nun an Zeit ist einmal darüber zu schreiben. Vielleicht kann ich es mir dann besser merken. Die Rede ist vom Einsatz von User-Controls in Repeatern.

Meine Webs basieren sehr stark auf Repeatern, weil ich zum einen die volle Kontrolle über den erzeugten Markup behalten möchte und zum anderen, weil ich die Inline-Style-Orgien, die man verursacht, wenn man vorgefertigte Controls wie das GridView verwendet und dabei dessen Attribute zum "Formatieren" der Ausgabe benutzt, ablehne. Styles gehören für mich in eingebundene CSS-Dateien.

<asp:Repeater ID="Repeater1" runat="server">
    <ItemTemplate>
        <div class="myclass">
            <a href="<%#Eval("LinkUrl")%>"><%#Eval("LinkText")%></a>
        </div>
    </ItemTemplate>
</asp:Repeater>    

Genauso wichtig ist für mich ein gerüttelt Maß an "Code-Normalisierung", d.h. immer wiederkehrende Elemente sollten in User-Controls zusammengefasst und vereinheitlicht werden. So braucht man kleine Änderungen am Layout nicht x-Mal durchzuführen, sondern man passt einmal das Control an und fertig. Alle Daten, die das Control benötigt, werden dabei über Properties von außen übergeben und zum Beispiel im Markup des Control über Inline-Code in den auszugebenden Markup eingesteuert.

<%@ Control 
    Language="VB" 
    AutoEventWireup="false" 
    CodeFile="MyControl.ascx.vb" 
    Inherits="controls_MyControl" %>

<div class="myclass">
    <a href="<%=Me.LinkUrl%>"><%=Me.LinkText%></a>
</div>

Beide Vorgehensweisen zusammen haben allerdings einen kleinen aber feinen Haken, wenn man den Repeater in der Hauptseite belassen muss und mit der Methode Eval("Feldname"), der Kurzform von Eval(Container.DataItem, "Feldname"), dem User-Control die Daten übergeben möchte. Schauen wir uns mal eine 1:1-Umsetzung der Hauptseite des Beispiels an:

Aufgrund des aktuell recht miesen Ladeverhaltens der auf zerbit.de bislang verwendeten live-Searchbox für die Suche in diesem Web, habe ich mich entschlossen BOSS (Build your own Search Engine) von Yahoo einmal auszuprobieren. Schön an dieser Lösung ist, daß man die Suchergebnisse über eine API im XML-Format abrufen und sie dann nahtlos in das Layout der eigenen Seite integrieren kann.

Notwendig war in diesem Zusammenhang natürlich auch ein Seiten-Navigator, wie man ihn auf Suchergebnisseiten gewohnt ist. Je nachdem wieviele Gesamttreffer eine Suche ergibt und wieviele Treffer auf einer Seite dargestellt werden, sollten unterschiedlich viele Seiten-Links (dargestellt als kleine Buttons) im Navigator enthalten sein, jedoch maximal 15 um einzeilig zu bleiben. Bei der Anzeige einer Seite größer als 15, sollte der Navigator "nach rechts rollen", d.h. der erste darzustellende Seiten-Link sollte sich um eins verschieben, bis die maximale Anzahl an Seiten erreicht ist.

Möglichkeiten

Eine mögliche Lösung für die Implementierung des Navigators wären statische Hyperlink-Controls gewesen, die in Abhängigkeit der anzuzeigenden Trefferseite ihren Text und ihren Link ändern, aber damit wäre die maximale Anzahl an Seitenlinks per Code auf 15 zementiert und wenig Raum für eine schnelle Anpassung, wenn es dann doch einmal mehr sein sollten. Die größte Flexibilität wäre erreicht, wenn man in der web-config definieren könnte, wie "breit" der Navigator sein soll und der Code dies dynamisch in HTML umsetzt.

Für dieses Problem bietet ASP.NET über die Methode Controls.Add die Möglichkeit zur Laufzeit Steuerelemente in einen beliebigen Container einzufügen, wie unter anderem Uwe Grone in seinem MSDN Solve Artikel beschreibt.

  Dim lnk As HyperLink = New HyperLink()
  lnk.Text = "..."
  lnk.NavigateUrl = "..."
  Me.Panel1.Controls.Add(lnk)

Dieser Ansatz hat allerdings den Haken, dass das Hyperlink-Control keinen Konstruktor bietet, mit dem man die notwendigen Attribute direkt übergeben kann. Bei einer nicht bekannten Anzahl an zu erzeugenden Controls kommt da recht viel Code zustande, vor allem, wenn man zwei Navigatoren braucht: einen oben auf der Seite und den anderen unten.

Webmaster, wie ich, die auf Ihrer Web-Site selbstentwickelte Tools zur Verfügung stellen, haben stets das gleiche Problem, wenn sie eine neue Version veröffentlichen wollen: neben der Erstellung des Downloads-Pakets, muss man auch noch den neuen Download über einen angepassten Link in die Seiten einbinden, sofern aus dem Dateinamen ersichtlich werden soll, um welche Version es sich handelt.

Mit etwas Code lässt sich das Deployment solcher Pakete aber auf den reinen FTP-Upload beschränken. Soll sich die Seite doch selbst den aktuellen Download heraussuchen...

In ASP.NET lässt sich das Ganze wunderbar in ein UserControl verpacken, sodaß man beim Entwickeln der Web-Seiten schnell einen neuen Download deklarieren kann, ohne erneut viel Code zu schreiben.