Hey, Hey, Wiki – welches Wiki paßt zu mir?

Ich will jetzt endlich auch einmal ein Wiki haben. Eines für mich und meine Kollegen.

Ein bissl rumgesucht und schon gefunden: ProntoWiki. Weil’s in C# geschrieben ist, eine gscheide SQL-Datenbank unterstützt und vor allem weil das Programm sehr übersichtlich ausschaut, so daß ich mir Änderungen und Erweiterungen selbst zutraue.

Hätte ich also nicht schon ein passendes Wiki gefunden – tja, dann müßte ich wohl bei WikiMatrix vorbeischauen. Hier kann man 88 Wikis miteinander vergleichen. Von SocialText bis TikiWiki (was für ein Name!). Und man kann suchen: will man eines in C# oder eines in Ruby? Ganz interessant ist hier die frei zusammenklickbare Suche über viele Kriterien.

Naja, vielleicht schau’ ich doch nochmal vorbei und finde ein noch passenderes??
Mal schauen…

NULL-Werte in DropDownList

Eine DropDownList soll dynamisch mit Inhalten aus einer Tabelle (B) gefüllt werden. Der ausgewählte Index soll als Schlüssel in Tabelle (A) eingefügt werden.

Dies realisiert man relativ einfach durch Datenbindung. Dabei wird der SelectedValue des DropDownfeldes mit der Spalte in Tabelle (A) verknüpft:

Als Datenquelle für die Liste im DropDownList wird eine entsprechende DataSource gewählt:

Und schon klappts – Naja fast.

Will man nämlich auch „keinen Wert“ auswählen hat man ein kleines Problem. Denn der Wert „nichts“ (oder NULL) ist in der Tabelle (B) nicht enthalten. Versucht man nun einen Datensatz anzuzeigen, der in Tabelle (A) im Fremdschlüsselfeld den Wert NULL enthält, bekommt man folgenden Fehler:

Da in Tabelle (B) der Wert NULL nicht vorhanden ist, weiß das Programm nicht, welchen Wert es in der DropDownList anzeigen soll (weil es nicht in der Elementliste vorhanden ist). Um dennoch NULL-Werte (also nix) auswählen zu können ist folgende simple Erweiterung des DropDownList erforderlich:

Die Eigenschaft „AppendDataBoundItems“ des DropDownList wird auf True gesetzt. Damit „mischt“ man die statisch eingegebenen Einträge mit denen, die aus der DataSource kommen.

Für den NULL-Wert fügt man nun unter ITEMS einen Leer-Wert hinzu – und fertig ist das Ganze.

Nun besteht die Liste im DropDownList aus den Werten aus der Datenbank und einem einzelnen leeren Wert, den wir manuell hinzugefügt haben.

AJAX ist .net(t) – oder: Wie hoch dürfen Hochsprachen sein?

Es gab Zeiten, da programmierte ich auf meinem Commodore 64 in Assembler. Es kamen tatsächlich funktionierende Programme dabei heraus, von denen ich jedes Bit und Byte kannte.

mov ds, ax
mov dx, offset Meldung
mov ah, 9
int 21h
…

Später kamen dann Hochsprachen wie Pascal (Turbo Pascal 5.5), ObjectPAL (Paradox) und Object Pascal (Delphi 3-7) dazu. Mittlerweile bin ich bei C# (Visual Studio 2005) gelandet und mache meine ersten Schritte mit dem AJAX.NET-Aufsatz von Microsoft.

Komplexe Vorgänge, komplizierte Techniken werden mit den Hochsprachen und modernen integrierten Entwicklungsumgebungen (IDE) mit wenigen Klicks und oft genug ohne eine Zeile Code erzeugt. Da stellt sich die Frage: „Wie hoch dürfen Hochsprachen eigentlich sein?“ Oder anders: „Wieviel muß ein Entwickler noch von dem wissen, was die DIE für ihn erledigt?“

Sicherlich muß heute kaum noch ein Anwendungsentwickler bis in die Assembler-Ebene vordringen. Doch wo sind die Grenzen? Muß ein Entwickler, der AJAX-Technologie verwendet, etwas von JavaScript verstehen? Muß ich mir den von Visual Studio generierten HTML-Code meiner ASP.net Anwendung anschauen und jede Zeile generierten JavaScripts verstehen?

Ich denke: Sicher nicht! Fortschritt besteht in der Spezialisierung und in der Abstraktion von Prozessen. Jeder fährt Auto – doch reparieren könnes es nur wenige. Viele essen Brot – doch nicht jeder ist Bäcker. Man überläßt Spezialisten diese oder jene Aufgabe. Dadurch konnte sich die Menschheit vom Jäger und Sammler (Alleskönner) zur heutigen Welt der Arbeits- und Aufgabenteilung (Spezialisten) entwickeln.

So auch in der Software-Entwicklung. Spezialisten kreieren Werkzeuge, die mir als Entwickler viel „tiefes“ abnehmen (z.B. Assembler). So bleibt (im Idealfall) Zeit für „höheres“, für die eigentliche Problemlösung.

Im Idealfall – wie gesagt. Denn oft sind heute die Dinge noch so komplex, daß die Spezialisten Fehler machen, die mich dann wieder in die Tiefen zwignen und mich mit Sachen konfrontieren, die ich eigentlich nicht machen will. Z.B. JavaScript. Mit AJAX.net läuft meine Ajax-Anwendung – ohne daß ich JavaScript kann. Solange die Spezialisten gute Arbeit machten.

Mag sein, daß erst die Zukunft eine ideale Welt der Softwareentwicklung bringen wird, in der die Tools auch wirklich funktionieren und halten was sie versprechen. Aber sie werden immer besser. Und schön ist es auch schon heute, gemeinsam mit Freunden zu programmieren und zu staunen, was alles möglich ist, was per „Klick“ machbar ist.

Gut, daß ich nicht mehr Assembler programmieren muß.
Und gut, daß AJAX.net mit JavaScript abnimmt – auch wenn ich es mir bestimmt mal ein bissl anschauen werde…

Wer braucht schon GridView.RenderControl() ?

Da habe ich mich stundenlang durchs Internet gequält um herauszufinden, dass GridView.RenderControl() nicht richtig funktioniert – und dabei ist es wieder mal relativ einfach. Wenn man’s denn selber macht!

Also „rendere“ ich mein GridView doch gleich selber – ich durchlaufe alle Zeilen und Spalten und bastle mir daraus eine kleine HTML-Tabelle. Fertig. Excel versteht das! Und das Ganze hat noch den Vorteil: ich weiß was da passiert – und kann meine HTML-Tabelle so anpassen wie ich will! Also z.B. jede zweite Zeile farbig markieren und ähnliche Scherze.
Warum eigentlich nicht gleich so?

    public static string GetGridViewAsHTML(GridView gv)
    /// Wandelt ein Gridview in eine HTML-Tabelle um
    {
        int Spalten = gv.Columns.Count;
        int Zeilen = gv.Rows.Count;
        string ausgabe = „<table border=1><tr style=\“color:blue\“>“;
        string wert = „“;
        
        for (int s = 0; s < Spalten; s++)
        {
            ausgabe += „<th>“+gv.Columns[s].HeaderText + „</th>“;
        }
        ausgabe += „</tr><tr>“;

        for (int z = 0; z < Zeilen; z++)
        {
            for (int s = 0; s < Spalten; s++)
            {
                wert = gv.Rows[z].Cells[s].Text;
                ausgabe += „<td>“ + wert + „</td>“;
            }
            ausgabe += „</tr><tr>“; 
        }
        ausgabe += „</tr></table>“;
        return ausgabe;
    }

GridView.RenderControl() – oder wie ich lernte, Microsoft zu hassen…

Update: Problem umgangen – hier nachzulesen...

Eigentlich wollte ich nur ein GridView aus meiner ASP.NET-Anwendung nach Excel exportieren. Mehr nicht. Aber aus diesem Vorhaben wurde ein Unterfangen das mich lehrte, Microsoft zu hassen…

Aus ASP.NET kann man relativ leicht Daten nach Excel exportieren. Man muß nur die zu übertragenden Daten als HTML-Tabelle an Excel senden. Excel versteht diese HTMl-Tabelle und kann sie problemlos als Quasi-Excel-Sheet laden.

Und es ist auch ganz einfach ein Control – wie etwa ein GridView oder DataGrid – in HTML-Code umzuwandeln. Dazu gibt es in ASP.NET den Befehl RenderControl(StringWriter).

Such man im Internet nach Excel-Export und GridView bzw. DataGrid, findet man immer wieder Code-Beispiele, die diese beiden einfachen Dinge zusammenführen. Ein Grid wird nach HTML gerendert und als Excel-Anwendungsdaten zurückgeschickt.

Response.ClearContent();
Response.AddHeader(„content-disposition“, „attachment;
filename=MyExcelFile.xls“);
Response.ContentType = „application/excel“;
StringWriter sw = new StringWriter();
HtmlTextWriter htw = new HtmlTextWriter(sw);
TestGrid.RenderControl(htw);
Response.Write(sw.ToString());
Response.End();

Diese Code funktioniert einwandfrei – sofern man ein DataGrid verwendet. Dieses alte Grid wurde in Visual Studio 2005 bekanntermaßen durch das neue GridView abgelöst.

Wendet man nun den obigen Code auf ein GridView an – das ja sooo viel besser, genialer, revolutionärer ist als das DataGrid – erhält man diese Fehlermeldung:

Das Steuerelement ctl00_ContentPlaceholder1_TestGrid vom Typ GridView muss in einem Formulartag mit runat=server positioniert werden

Häähhh??
Natürlich befindet sich das GridView automatisch innerhalb eines Formulartags mit runat=“Server“ – schließlich hat VS 2005 den Code für mich generiert. Was bedeutet also diese sinnlose Fehlermeldung? Ich weiß es nicht.

Nach einigem suchen im Internet findet man dann heraus, dass diese Fehlermeldung ein Bug in VS 2005 ist, den man umgehen kann, wenn man folgenden, wunderbaren, logischen, selbsterklärenden und einfachen Code in seine aspx-Seite mit aufnimmt:

public override void VerifyRenderingInServerForm(Control control)
{

}

Jeder vernünftige Compiler den ich kenne würde solchen Code automatisch herauscompilieren. Nutzloser Code. Ohne Funktionalität. Ohne Sinn.

Und doch – läßt man das Programm mit dieser leeren Funktion laufen erhält man tatsächlich eine Excel-Tabelle, ohne jede weitere Fehlermeldung.

Naja, zumindest meistens. Nicht immer. Denn wenn das GridView weitere Controls enthält, wie z.B. Editierbuttons, Spalten mit Checkboxen, oder das Grid ganz einfach Sortierung und Paging erlaubt – dann kracht es erneut:

RegisterForEventValidation kann nur während Render() aufgerufen werden;

Aha. Logisch. Oder? Oder etwas nicht?
Ich kapiere es nicht – und suche mir wieder einen Wolf im Internet. Und finde heraus, dass diese Fehlermeldung umgangen werden kann, wenn man in die Seitendirektive folgenden Wert eingibt:

EnableEventValidation=“false“

Also:

<%@ Page Language=“C#“ EnableEventValidation=“false“ AutoEventWireup=“true“ CodeFile=“Default.aspx.cs“ Inherits=“_Default“ %>

Jetzt aber! Nun funktioniert der Export eines GridViews nach Excel. Hurra!

Ich habe ja auch nur gut 4 Stunden gebraucht, um all das herauszufinden.

Das regt mich an Visual Studio 2005 so unendlich auf. Man will was machen und findet sehr schnell im Internet entsprechende Lösungen bzw. Beispielcodes, wie etwas gehen könnte. Doch geht man dann in die Tiefe, taucht ein Problem nach dem anderen auf. Wie ein Dominoeffekt.
Nach dem Motto: „Hurra – ich bin eine Fehlermeldung weiter“ – nächster Level!! Yeahhh.

Um so ärgerlicher ist es, wenn man dann auch noch an Bugs von Microsoft scheitert. Wenn man einen Workaround für einen Fehler braucht, und wenn er nur aus einer leeren Routine besteht.

Doch manchmal habe ich den Verdacht, das sind gar keine Bugs. Das ist pure Absicht! Microsoft will ganz einfach in möglichst vielen Blogs von verzweifelten Entwicklern auftauchen! Das ist Microschufts Art, den Goolge-Page-Rank zu erhöhen! Jawohl! SEO (search engine optimization)) der ganz besonderen Art!