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.

Zugriffe auf Datenbanken wie SQL-Server oder andere, sollten in jeder Anwendung aufs Nötigste beschränkt werden. Um ein paar Daten zum Beispiel auf eine WebForm zu bringen 3, 4 mal die Datenbank zu konsultieren, bis man alle Daten zusammen hat, ist ineffizient und bedeutet Perfomance-Verlust.

Bei der Anzeige hierarchisch strukturierter Daten wird dieser mehrfache Zugriff jedoch oft in Kauf genommen, um die einzelnen Ebenen getrennt voneinander verarbeiten zu können. In Zeiten von LINQ ist dies eigentlich unnötig, da man hier Daten auch gruppieren kann. Jedoch gibt es auch Alternativen, wenn zum Beispiel der Web-Provider das .NET-Framework 3.5 noch nicht unterstützt oder man die Einarbeitungszeit in LINQ scheut. Auch können LINQ-Statements mit 5 oder 6 Ebenen extrem unübersichtlich werden und somit die Wartbarkeit des Codes verschlechtern.

Die kostenfreien Microsoft ASP.NET Chart Controls, die zum Teil auf den Dundas-Charts basieren, sollen ja mit der Version 4.0 Einzug in das .NET-Framework halten. Fein, aber was machen wir bis dahin? Ganz einfach: MSChart.exe herunterladen und installieren...

Das funktioniert allerdings bei einigen Providern nicht, da diese sich (aus verständlichen Gründen) schlicht weigern zusätzliche Software auf ihren Maschinen zu installieren. Es geht aber auch ohne Installation. Hier eine kleine Anleitung:

Assembly

Zuständig für die Erzeugung der Chart-Bilder ist die System.Web.DataVisualization.dll aus dem kostenfrei herunterladbaren Installationspaket MSChart.exe.

Wie im .NET-Framework üblich, schreibt das Setup-Paket alle beteiligten DLL's in den Global Assembly Cache. Aus diesem muss man nun erstmal o.g. Assembly herausfischen. Wie das am einfachsten funktioniert habe ich im Artikel GAC-Viewer unter Windows XP beschrieben.

Die DLL kopiert man einfach in das bin-Verzeichnis der Web-Anwendung.

Die in ASP.NET integrierten SQL-Membership- und Profile-Provider sind schon eine feine Sache. Sie bieten vom Start weg eine Menge Funktionalitäten, die dem Entwickler das Leben erleichtern. Vor allem der Profile-Provider ist sehr effektiv: man deklariert in der web.config ein neues Feld und kann es direkt verwenden, um die Stammdaten eines Benutzers um eigene Felder zu erweitern.

Der Membership-Provider bietet, neben der Verwaltung der Benutzer, einige Zusatzfunktionen, um den Status eines Benutzers abzufragen, wie IsOnline oder GetNumberOfUsersOnline, die sich zum Beispiel gut dafür eignen auf einer Administrationseite anzuzeigen welche User gerade angemeldet sind. Bezugspunkt für diese beiden Eigenschaften bzw. Methoden ist das Feld LastActivityDate, in dem die letzte Aktivität des Users festgehalten wird, und die Membership-Eigenschaft UserIsOnlineTimeWindow. Aus der Differenz errechnet sich, ob ein Benutzer noch online ist oder vielleicht nicht (ASP.NET ist halt zustandslos).

Problem

Beim Einsatz des Profile-Providers gibt es dabei allerdings einen Haken: sobald auf ein Profil-Feld zugegriffen wird, aktualisiert der Provider das LastActivityDate des dazugehörigen Benutzers! Das ist das Phänomen, dass vielleicht einige Admins kennen. Man lädt die User-Liste mit zusätzlichen Informationen aus dem Profil und scheinbar sind alle User gerade online...