Der-Albert.com sein Blog!

Vortrag zur Windows Presentation Foundation am 05.12.2006

Mit der Windows Presentation Foundation (WPF) hat Microsoft nach über 20 Jahren Windows das erste Mal tatsächlich etwas grundlegend Neues zum Erstellen von Windows und Web Anwendungen geschaffen. Das Ergebnis ist wirklich beeindruckend geworden und wird die Windows Entwicklung nachhaltig verändern. In meinem Vortrag möchte ich den Versuch unternehmen Software Entwicklern die wichtigsten Konzepte anhand von Beispielen vorzustellen und auch einen kurzen Einblick in die kommenden Entwicklungswerkzeuge zu geben. Ziel des Vortrags ist es, einen Eindruck zu vermitteln, welche phantastischen Möglichkeiten sich durch den Einsatz der Windows Presentation Foundation eröffnen.

optgroup bei DropDownList via ControlAdapter

Leider hat es MS ja mit ASP.NET 2.0 nicht geschafft auch <optgroup /> zu unterstützen. Damit könnte man die Einträge innerhalb DropDownList gruppieren. Dies würde dann so aussehen.

Dies kann man jedoch leicht nachrüsten, entweder mit einem eigenen Control oder mit einem Adapter. Wie? Das soll hier gezeigt werden. ControlAdapter sind eine ganz nette Erfindung von Microsoft, damit kann man das verhalten der eingebauten Controls überschreiben. Den Weg über den ControlAdapter hat jemand bei The Code Project [1] vollzogen.

Leider hat die veröffentliche Variante einige Probleme beim Postback, da keinerlei Viewstate verwaltet wird, und somit die Validierung nicht möglich ist und die Gruppierung verloren geht. Ich habe das ganze ein wenig aufgeräumt, die Viewstate Unterstützung eingebaut und es ist was brauchbares dabei rumgekommmen, warum soll es also weiter nur auf meiner Festplatte versauern. Die Anwendung ist denkbar einfach, ein vorhandenes ListItem muss einfach um das Attribute "optionGroup" mit dem Namen der Gruppe erweitert werden. Dies entweder direkt im Markup-Code

<asp:DropDownList id="foo" runat="server" />
<asp:ListItem optionGroup="Gruppe1">Eintrag 1</asp:ListItem>
<asp:ListItem optionGroup="Gruppe1">Eintrag 2</asp:ListItem>
<asp:ListItem optionGroup="Gruppe2">Eintrag 3</asp:ListItem>
<asp:ListItem optionGroup="Gruppe2">Eintrag 4</asp:ListItem>
<asp:ListItem optionGroup="Gruppe3">Eintrag 5</asp:ListItem>
<asp:ListItem optionGroup="Gruppe3">Eintrag 6</asp:ListItem>
<asp:ListItem optionGroup="Gruppe3">Eintrag 7</asp:ListItem>
<asp:ListItem optionGroup="Gruppe4">Eintrag 8</asp:ListItem>
</asp:DropDownList>

oder via Programm-Code

ListItem item = new ListItem();
item.Attributes["optionGroup"] = "Gruppe1"; 

In diesem ControlAdapter wird RenderContents() um die ListItems entsprechend zu rendern und in eine <optgroup /> zu packen. Für den ViewState wird dann noch LoadAdapterViewState() und SaveAdapterViewState() überschrieben. Wichtig ist dann noch nach dem wiederherstellen nach dem laden des ViewsStates die optionGroup Einstellungen wieder herzustellen, die passiert passenderweise in OnPreRender(). Damit die Event Validierung nicht fehlschlägt muss jeder Wert der ListItems noch mit Page.ClientScript.RegisterForEventValidation() registriert werden. Der ControlAdapter dann einfach nur noch in die Webanwendung einbauen. Dazu die beigefügte DropDownList.browser Datei in den Ordner App_Browsers ablegen, ist dieser nicht da, dann einfach anlegen. Viel Spaß.

[1] http://www.codeproject.com/aspnet/DropDownListOptionGroup.asp

[2] http://der-albert.com/uploads/DropDownListAdapter.zip

Anti-Cross Site Scripting Library nun in der Version 1.5 verfügbar

Interfaces müssen nicht implementiert werden!

Aus der Abteilung, Sprachfeatures die vielleicht nicht jeder kennt. Derzeit ja schwer in Mode in den Blogs :), ein Trend auf den ich mal aufspringe.     Diesmal das Interface:   

"Landläufige" Meinung: Erstellt man ein Interface, dann muss eine darauf aufbauende Klasse alle Methode und Eigenschaften implemtieren. Falsch[:  Muss sie nicht!   Jedenfalls nicht wenn sie schon implemtiert sind, z. B. in einer Basisklasse. Und dies ist auch ganz praktisch. Dies zeige ich hier an einem einem Beispiel.    

Wenn ich z.B. mit dem Modell View Presenter Pattern [1] eine Anwendungsoberfläche erstelle und dort den Presenter einen passiven View steuern lasse. Dann braucht der Presenter, je nach Variation des MVP-Patterns, Zugriff auf die Controls, jedoch ist es nicht unbedingt ratsam die eigentliche Control-Objekte nach "draußen" zu führen.

Da man sich damit die Möglichkeit verbaut den Presenter auch für verschiedenen View-Variationen einzusetzen.     Denn stellt man es halbwegs geschickt an, so kann der gleiche Presenter für WebForms, WinForms oder GTK# (bei Mono) eingesetzt werden. So das ein großteil der GUI Logik (füllen mit Daten, Zustände der Controls, Überprüfung der Eingaben) nur einmal geschrieben werden muss.    Leider hat Microsoft beim .NET Framework es ja verpasst die ASP.NET Controls und WinForms Controls auf eine halbwegs gemeinsame Basis zu stellen. Doch mit Interfaces kann dem ein wenig nachgeholfen werden. Ohne das man, bei den meisten Controls, viel Programmieren muss.    So habe ich z.B. in einer Anwendung mir folgende Interfaces definiert um z.B. einen Button zu steuern.   

public interface IControl
{
    bool Enabled { get; set; }
    bool Visible { get; set; }
    void Focus();
}

public interface IButton : IControl
{
    string Text { get; set; }
    event EventHandler Click;
}

Damit ich mit dem Interface auch arbeiten kann muss ich mir selbstverständlich einen eigenen Button erstellen, der darauf basiert. Denn ein Arbeiten mit &lt;asp:Button /&gt; fällt flach, da er weder dieses Interface noch ein anderes ähnliches Interface kennt.    Doch mit diesem gewählten Interface fällt die Implementierung eines eigenen Buttons trotzdem sehr klar und einfach aus.   

namespace DerAlbert.BaseControls.Web
{
    public class Button : System.Web.UI.WebControls.Button, IButton
    {
    }
}

Das war es schon, fertig ist mein eigener Button und kann einer Webanwendung einsetzen. Das Interface muss nun nicht mehr implementiert werden, da die Basisklasse schon eine Implementation der Methoden und Eigenschaften zu Verfügung stellt, unabhängig von meinem Interface.    Dies ist ein wesentlicher Unterschied zwischen Interfaces und rein abstrakten Klassen wie sie z.B. in C++ eingesetzt werden um ähnliches zu erreichen.    In der Anwendung sieht dies dann so aus, ich definiere eine Inteface für ein View 

namespace DerAlbert.Community.Views
{
    public interface IImagesEditView : IView
    {
        IButton ButtonSave { get; }
    }
}

    Nun baue ich mir eine entsprechende Form auf Basis dieses Interface und entwickle den Presenter gegen dieses Interface. Fertig ist mein universeller Presenter.    Mit einem WinForm Button ist dies auch möglich, so kann ich den Presenter gegen das Interface des Controls entwickeln und muss mich nicht drum kümmern ob WinForm, WebForm und hoffentlich auch WPF.    Natürlich ist nicht jedes Control so einfach umzusetzen. Für ein DropDownList oder TreeView muss man schon ein paar Hindernisse aus dem Weg räumen um sowohl das Control sowie ListItem und TreeNode mit einem Interface zu versehen.    Auch gleichen sich WebForm und WinForm nicht in allen Controls so einfach wie beim Button, dann muss man halt dass was jeweils anders ist nachprogrammieren. Doch dies ist ein einmaliger Aufwand.   

  [1] http://martinfowler.com/eaaDev/

HTMLElement-Scrollposition bei einem PostBack merken

Heute in den Newsgroups [2], es fragte Fabian Nowothnik danach wie man nach einem Postback die Scrollpositionen von einzelnen Elementen wieder herstellen kann.

Für die Scrollposition der Seite gibt es dies ja seit ASP.NET 2.0 schon in der Serienausstattung. Ein Scrolling innerhalb eines DIV-Elements "passiert" ja schnell, in dem innerhalb eine DIV-Elements mehr reinpackt als die festgesetzen Ausmaße zulassen. Nun einfach den CSS-Style "overflow:auto;" oder "overlow:scroll;" gesetzt dann kann man darin scrollen, jedoch verliert sich die Scroll-Position nach dem Postback. Das ist schade.

Prinzipiell sollte es doch ganz einfach sein etwas dagegen zu machen. Position der Elemente vor dem Postback merken und dann direkt einfach beim neuladen wieder herstellen. Wäre doch auch nett wenn man dies dann einfach via kleinem Control machen kann einfach auf jeder Seite einsetzen kann. Gesagt getan, hier ist das Ergebnis das "RememberElementScrollPosition" WebControl für ASP.NET 2.0 :).

Gleich vorweg, dazu ist JavaScript notwendig, ohne geht's nicht. Die Anwendung selbst ist denkbar einfach. Nachdem man den Quelltext [1] in eine Assembly oder App_Code Ordner gepackt hat muss man das Control dem Web bekannt machen, dazu in der Web.config zu der Controls-Auflistung hinzufügen, hier ein Beispiel, es muss den eigenen Gegebenheiten angepasst werden.

<system.web> 
  <pages> 
    <controls> 
      <add namespace="DerAlbert.Community.Web.UI.WebControls" 
           assembly="DerAlbert.Community.Web" 
           tagprefix="dac" /> 
    </controls> 
  </pages> 
</system.web>

Auf der Seite dann folgendes

<dac:rememberelementscrollposition id="RESP1" runat="server"> 
    <dac:controlid>MyPanel</dac:controlid> 
    <dac:controlid>Div1</dac:controlid> 
</dac:rememberelementscrollposition>

Für jedes Element/Control ein <dac:ControlID/> hinzufügen. Es wird erst das passenden Server-Control gesucht und verwendet, wird keins gefunden so wird die angegebene ID direkt als ClientID verwendet. So das man

<asp:panel id="MyPanel" runat="server">Der rieisige Inhalt</asp:panel> 

oder auch

<div id="Div1">Größer, schneller weiter</div>

verwenden kann. Je nach Vorliebe, aber eine ID muss vorhanden sein. Mehr muss man nicht machen.

Damit ich vor dem Postback die Daten auslesen kann Registriere ich mir mit ClientScript.RegisterOnSubmitStatement() eine Javascript Anweisung welche das sammeln der Scrollpositionen aufruft und in einem HiddenField ablegt, damit diese den Postback ohne weitere Tricks überleben. Beim wiederladen der Seite sollen die gespeicherten Positionen wieder gesetzt werden, dafür muss wieder eine JavaScript Anweisung registriert werden diesmal mit ClientScript.RegisterStartupScript(). Damit wird die übergebenen Anweisung ans Ende der Seite gelegt und automatisch aufgerufen nachdem der eigentliche Seiteninhalt schon vorhanden ist.

Das JavaScript selbst ist objektorientiert aufgebaut, sollte jedoch nicht so schwer sein zu verstehen. Es merkt sich die scrollTop und scrollLeft Werte des HTML-Elements und packt diese zusammen mit der ID des Elements in das Hiddenfield. Selbstverständlich für alle angebenen Elemente, jedoch nur wenn man die Element auch wirklich in einem "gescrolltem" Zustand sind. Nun genug geredet. Nutzt das Teil wenn Ihr wollt.

[1] Download Quelltext

[2] Newsgroup-Anfrage

.NET Framework 3.0 ist Final!

Download der MSDN Library August 2006

Generische ConfigurationElementCollection

Baut man sich für seine .NET 2.0 Anwendung eigene Konfigurationsbereiche, dann braucht man früher oder später auch eine Liste von Elementen. Braucht man dies öfters, dann wird es ein wenig nervig, da man ein wenig Grundtipparbeit für jede Auflistung hat. Hier ein generischer Ansatz für ConfigurationElementCollection.

public abstract class ConfigurationElementCollection<T> : ConfigurationElementCollection
        where T : ConfigurationElement
{
    protected override ConfigurationElement CreateNewElement()
    {
        return (ConfigurationElement)Activator.CreateInstance(typeof(T));
    }

    public T this[int index]
    {
        get { return (T)base.BaseGet(index); }
        set
        {
            if (base.BaseGet(index) != null)
            {
                base.BaseRemoveAt(index);
            }
            this.BaseAdd(index, value);
        }
    }

    public new T this[string key]
    {
        get { return (T)base.BaseGet(key); }
    }
}

Nun braucht man nur noch ein ConfigurationElement. Hier ein Beispiel aus einer aktuellen Anwendung von mir.

public class EntryObjectSettings : ConfigurationElement
{
    [ConfigurationProperty("name", IsRequired = true)]
    public string Name
    {
        get { return (string) base["name"]; }
        set { base["name"] = value; }
    }

    [ConfigurationProperty("type", IsRequired = true)]
    [TypeConverter(typeof (TypeTypeConverter))]
    [SubclassTypeValidator(typeof (BaseEntry))]
    public Type Type
    {
        get { return (Type) base["type"]; }
        set { base["type"] = value; }
    }

    [ConfigurationProperty("template", IsRequired = false)]
    [FileExistsValidator]
    public string Template
    {
        get { return (string) base["template"]; }
        set { base["template"] = value; }
    }
}

Jetzt erstellt man eine ConfigurationElementCollection für sein ConfigurationElement zu. Das einzige was nun noch gemacht werden muss, ist das überschreiben von GetElementKey() damit die Collection auch einen eindeutigen Key für jeden Eintrag erhält.

[ConfigurationCollection(typeof (EntryObjectSettings))]
public class EntryObjectSettingsCollection : ConfigurationElementCollection
{
    protected override object GetElementKey(ConfigurationElement element)
    {
        return ((EntryObjectSettings) element).Name;
    }
}
    

Mit einem eigenem Validator die Angaben in der Konfigurations-Datei überprüfen