I never really understood why the UpdatePanel was derived from Control instead of WebControl. It obviously represents a more or less visible web element but lacks the possibility to add class or style tags from codebehind. Maybe it is due to the updateable nature of the control, I don’t know. The only thing I now right now is that I want a CssClass property on my UpdatePanel. Thankfully thats an easy task, just create a new Control that derives from the UpdatePanel, add a „CssClass“ Property and add the contents to the attribute collection in the render method. This is how the class would look like (note that I use ASP.NET 3.X notation):

public class CustomUpdatePanel : System.Web.UI.UpdatePanel
{
    public string CssClass
    {
        get;
        set;
    }

    protected override void Render(HtmlTextWriter writer)
    {
        if (CssClass != string.Empty)
        {
            writer.AddAttribute(HtmlTextWriterAttribute.Class, CssClass);
        }

        base.Render(writer);
    }
}

I like it 😉 and it also comes really handy for UpdateProgress.

In den letzten Wochen habe ich ein Ursprüngliches ASP.Net 1.1 Projekt das auf ASP.Net 2.0 geupraded wurde um AJAX kontrollen erweitern müssen. Dabei sind mir ein paar Stolpersteine aufgefallen die zu ernsten Problemen führen können und nicht ohne weiteres ersichtlich sind.

Wenn man ein altes Projekt mit den AJAX kontrollen erweitern möchte sollte man folgende Punkte beachten:

• Ist eine Zugriffsverwaltung in der Applikation implementiert (z.b. automatische Umleitung) sollte dringends drauf geachtet werden, dass die Regeln für diese so angepasst werden, dass man Zugriff auf die ScriptResource.axd hat. Ohne diese Datei funktioniert gar nichts und man bekommt die schöne Meldung das „Sys“ nicht definiert sei.
• Wenn alles schick gerendert wird, beim click auf Kontrollen trotzdem keine Ajax Funktionen gefeuert werden sollte man überprüfen ob zufällig noch der „legacy“ mode in der Web.Config steht (in der Sektion „System.Web“): ‚<xhtmlConformance mode=“Legacy“/>‘. Ist dieser gesetzt sollte dringend überprüft werden ob dies nötig ist und wenn nicht rausschmeißen. Im Legacy mode werden noch die alten Separatoren in den Controlnamen generiert (früher „:“ heute „$“), damit kommen die Ajax Scripte aber nicht klar. Sind noch CustomControls im Einsatz die die ID von Hand zusammenbasteln sollten diese angepasst werden das sie mit der ClientID der Controls arbeiten.
• Hat man nach partiellen Postbacks „?“ statt Umlaute oder Sonderzeichen liegt das wahrscheinlich am „globalization“ Eintrag in der Web.Config. Offenbar kommt Ajax nicht mit anderen Zeichensätzen als utf-8 klar. egal welcher Eintrag hier steht es wird bei partiellen Updates utf-8 zurück gesendet. Möglicherweise kann man dafür sorgen das der Zeichensatz auch dann den in der Web.Config definierten Wert aufweist, allerdings ist mir nicht bekannt wie (wenn jemand einen Hinweis hat bitte einen Comment hinterlassen :)).

Das Sammeln dieser Hinweise hat mich den einen oder anderen schweißgebadeten Tag Fehlersuche gekostet, ich hoffe sie helfen 😉

… sonst kann man beim asp.net Seiten schreiben arg auf die Fresse fliegen.

Heute morgen habe ich in einer .aspx Seite einen Validator durch einen neuen austauschen wollen. Dazu hab ich den alten Validator auskommentiert und den neuen Integriert. Beim nächsten Postback ging dann der Validatorcheck in die Brüche.

Nach etlichem rumgesuche, gebastle und debugge (lasst ja die Finger von SharePoint gesteuerten Webseiten wenn ihr mehr als reine Datenerfassung machen wollt, debuggen ist die Hölle!) fand ich raus, dass das auskommentierte Control dennoch vom Server geladen wurde, auch wenn es nicht ins HTML gerendert wurde, so haben die generierten JavaScript Methoden für die Validierung das Element noch in ihrer Liste.

Wenn ihr also elemente aus der Seite haben wollt, insbesondere Validatoren, kommentiert sie nicht aus, löscht sie! oder stellt sicher das die Funktionalität sicher abgestellt ist.