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.

Irgendwie ist es schon peinlich. Da bringt Microsoft nach Veröffentlichung des IE6 jahrelang browser-technisch nichts mehr zustande (man hat Netscape ja geschlagen) und kontert neu aufkommende Browser wie Firefox und Co. viel zu spät mit halbherzigen Aktionen wie dem IE7 und aktuell dem IE8. Halbherzig deswegen, weil auch der neueste Browser sich teilweise immer noch nur durch Hacks dazu bewegen lässt Webseiten vernünftig zu rendern, obwohl er sich an Standards halten soll.
Mein Gott, wie oft fluche ich selbst über diese "Gewollt-aber-nicht-gekonnt-Web-Dinger" aus Redmond. Obwohl ich ein Fan der MS-Software bin: den Anspruch des "Technology Leadership" scheint Microsoft in Sachen Browser arg zu vernachlässigen. Andere sind da wesentlich innovativer, besser und schneller.

So zum Beispiel Google Chrome. Das durchdachte Konzept, die schnelle Javascript-Engine V8 und die bärenstarken Ladezeiten haben dazu geführt, dass ich inzwischen nur noch damit surfe. (Zum Entwickeln von Seiten ist allerdings weiterhin Firefox erste Wahl ;)

Angesichts eines Markanteils von ca. 65% für den IE (davon knapp 40% immer noch IE6 - ein Hammer!) und 3% für Chrome, haben die kreativen Google-Köpfe auf die verwegene Idee gebracht die IE-Redering-Engine Trident einfach durch die Webkit-Engine von Chrome auszutauschen! Der Hintergedanke ist wohl: Google Wave und andere zukünftige "Web 3.0"-Anwendungen werden es extrem schwer haben, vernünftig auf dem IE zu laufen. Bei der Verbreitung dieser Dinge kommt man aber nicht am IE vorbei und damit wird Geld verdienen schlußendlich schwierig.

Herausgekommen ist Google Chrome Frame, ein IE-Plugin, das die Entscheidung wie eine Webseite im IE gerendert wird dem PC-Administrator und dem Webentwickler überlässt. Microsoft ist außen vor...