Um Seitenelemente per Javascript mit Server-Code zu aktualisieren statt die Seite neu zu laden, bietet ASP.NET seit Langem den ICallbackEventHandler. Mit der Einführung von ASP.NET AJAX haben sich die Möglichkeiten allerdings drastisch vervielfacht und die Implementierung von AJAX-Funktionalität geht mittels WebServices und WebMethods wesentlich einfacher von der Hand.

Das Web ist ohne Javascript heute kaum noch denkbar. Viele Webseiten implementieren client-seitige Funktionalität, statt alles bereits vorberechnet vom Server zu ziehen. Dementsprechend groß sind mitunter dann auch die Javascripts, die in den Browser geladen werden müssen.

Bandbreite ist zwar kaum noch ein Problem, aber die Benutzer erwarten doch einen schnellen Seitenaufbau. Ein wichtiger Ansatz ist dabei die Funktionen in mehrere kleine Javascript-Dateien zu kapseln und nur die zu laden, die man wirklich benötigt. Aber auch hier kommen schnell einige tausend Zeilen Javascript-Code zusammen. Um die Dateigröße möglichst klein zu halten, bietet sich eine Komprimierung an, wie man sie von ZIP- oder RAR-Archiven her kennt.

Einen wirklich effektiven Packer für Javascript hat der Engländer Dean Edwards vor einigen Jahren veröffentlicht. Das Ding ist sehr effektiv und wohl auch deshalb unter Web-Entwicklern recht beliebt. So komprimiert unter anderem die Truppe um John Resig die Sourcen von jQuery seit der ersten Version mit diesem Algorithmus.

Unter /packer/ bietet Dean ein Web-Formular, mit dem man Scripte sehr schnell und bequem manuell komprimieren kann. Für eine programmatische Komprimierung findet man auf der Seite Links zu einigen Portierungen des Tools in Sprachen wie PHP, Perl, WSH und .NET.

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:

Scrott Guthie, seines Zeichens Vice President der Microsoft Developer Division, hat in seinem Blog angekündigt, zukünftig John Resigs grandiose Javascript-Library jQuery nicht nur aktiv zu unterstützen (Intellisense, et cetera), sondern mit künftigen Visual Studio-Versionen auszuliefern! jQuery wird Teil der Microsoft'schen Entwicklungsplattform!

Scott Guthrie:

I'm excited today to announce that Microsoft will be shipping jQuery with Visual Studio going forward. We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch. The files will continue to use and ship under the existing jQuery MIT license.

John Resig:

Microsoft is looking to make jQuery part of their official development platform. Their JavaScript offering today includes the ASP.NET Ajax Framework and they?re looking to expand it with the use of jQuery. This means that jQuery will be distributed with Visual Studio (which will include jQuery intellisense, snippets, examples, and documentation).

Das nenne ich mal eine gute Nachricht. Ich bin ja bekennender jQuery-Fan und habe bereits mehrfach darüber geschrieben. Besonders interessant an der Meldung finde ich allerdings, daß man in Redmond die Bibliothek auch zur Weiterentwicklung der eigenen AJAX-Controls nutzen möchte und daß man sich ihm Rahmen der Entwicklungsstandards der Entwickler-Crew aktiv an der Weiterentwicklung von jQuery beteiligen möchte.

In einem ersten Schritt wird jQuery wohl in die finale Version des ASP.NET MVC Einzug halten, bevor der Rest der ASP.NET-Gemeinde mit entsprechenden Visual-Studio-Versionen rechnen kann. In einigen Wochen, so Scott, wird es aber bereits einen Download geben, der das VS 2008 direkt mit jQuery-Intellisense-Funktionen nachrüstet. Wie dies manuell umgesetzt werden kann, habe ich ja bereits vor einiger Zeit im Artikel jQuery & Visual Studio 2008 Intellisense beschrieben.

Bei der Entwicklung von ASP.NET-Webs soll es schon hin und wieder vorgekommen sein, daß gewisse eMail-Funktionalitäten implementiert werden mussten. So ist wohl hinlänglich bekannt, daß man in der web.config an zentraler Stelle den dafür notwendigen SMTP-Server konfigurieren kann:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="Network" from="admin@meinewebsite.de">
      <network host="smtp.meinewebsite.de" port="25"/>
    </smtp>
  </mailSettings>
</system.net>

Das Testen gestaltet sich in der Entwicklungsumgebung (Visual Studio und Cassini-Web-Server) aber etwas schwieriger, denn kaum ein Provider läßt es zu, daß von außen eMails in den SMTP-Server gekippt werden. Spam sei Dank...

Der einzig gangbare Weg scheint der über den in den diversen Windows-Version integrierte IIS zu sein, den man dann zum Debuggen verwenden muss. Aber ... es geht ein wenig einfacher, wenn man sich die Attribute des smtp-Tags in der web.config mal ein wenig genauer ansieht. Dort gibt es für das deliveryMethod-Attribut den Wert SpecifiedPickupDirectory.