An sich ist die Sache aj auch in ASP ganz easy und in vielen Blogposts beschrieben, beispielsweise bei den Dotnetslackers. Das Problem ist nur, dass bei diesem Ansatz die Datei erst nach einem Postback generiert und an den Client geschickt wird, dieser Postback aber das momentan angezeigte Formular nicht neu vom Server lädt. Problem? Wieso Problem?

Ganz einfach: Sharepoint meint es gut mit uns und sorgt per JavaScript dafür, dass Formulare nicht öfter als einmal abgeschickt werden können, beispielsweise durch amokklickende Benutzer. Das führt dazu, dass nach dem Download der Datei das Formular hinüber ist, d.h. es nicht mehr abgeschickt werden kann, weil es ja schon mal abgeschickt wurde. Sehr blöde, und die Lösungen, von denen ich gelesen habe, waren allesamt extrem kompliziert zu implementieren, weil sie irgendwelche speziellen Download-Handler vorgesehen haben. Mensch, Leute, ich habe eine Deadline und nicht beliebig viel Budget - ich brauche eine EINFACHE Lösung. Meinetwegen auch einen kleinen Hack.

Einen solchen Hack habe ich dann auch hinbekommen. Diese Resubmit-Sperre wird von Sharepoint nämlich im onsubmit-Handler des Formulars aufgerufen, so dass man nur beim Klick auf den Downloadbutton genau diesen Handler wegschießen muss:

exportButton = new Button();
exportButton.Text = “Generate some Excel stuff”;

// the handler method generates the file, writes it to the response and ends the response.
exportButton.Click += onExcelExportClicked;

// erase the form’s onsubmit handler when the button is clicked
exportButton.OnClientClick = “this.form.onsubmit = function() {return true;}”;

Hässlich, ja, und eventuell auch gefährlich, wenn man nicht aufpasst, aber es funktioniert. Die nächste Verbesserung wird sein, dass ich irgendwie nach dem Download den ursprünglichen onsubmit-Handler wieder herstelle oder so - aber das mache ich erst, wenn ich es brauche.

(Nur, falls irgendwer sich wundert: Das Posting mit dem identischen Codebeispiel im MSDN-Forum ist nicht geklaut, sondern auch von mir.)

Also. Wir mussten neulich für einen Kunden Excel-Files erzeugen, und zwar total komplizierte. Das Ganze durfte natürlich keine Excel-Installation auf dem Server voraussetzen, und CSV war definitiv keine Option, logo. Ein Fluch bildete sich schon auf unseren Lippen, als Paul ein Toolkit fand, das sich zur Rettung unserer Hinterteile in letzter Sekunde eignete: TMS Flexcel Studio for .Net.

Dieses Flexcel-Dings kann nicht nur beliebige Excel-Dateien einlesen, die darin enthaltenen Formeln berechnen, die Inhalte beliebig verändern und dann wieder eine Excel-Datei ausspucken. Nein, das wäre ja noch harmlos. Es enthält auch eine Reporting-Engine und kann Excel-Files als PDF oder HTML rendern, wobei Excel-Charts als PNG ausgegeben werden. Besonders geil ist das beiligende Tool, das eine beliebige Excel-Datei einlesen und daraus den Sourcecode in C#, VB oder Delphi generieren kann, den man bräuchte, um die Quelldatei programmatisch zu erzeugen… Das muss man echt mal gesehen haben.

Ach ja: Der Sourcecode der gesamten Komponente inklusive PDF-Library liegt bei, wenn man das Tool für sagenhaft günstige 125 EUR pro Entwickler kauft. Für 495 EUR gibt’s eine “Site Licence”, die dann von beliebig vielen Entwicklern einer Firma benutzt werden darf - da kann man nicht meckern. Insbesondere dann nicht, wenn man sich überlegt, wieviel eine Excel-Lizenz für den Server kosten würde. Oder die Eigenentwicklung so einer Killerkomponente.

Und nein, ich bin nicht zum reinen Microsoftie verkommen. Ich arbeite halt momentan mehr oder weniger ausschließlich mit dem Zeugs, hoffe aber darauf, irgendwann mal wieder was mit Java machen zu dürfen - und dann kriegt Ihr auch wieder Blogposts, die sich nicht um den MS-Krempel drehen.

Man kann sich also vorstellen, wie glücklich ich war, als ich gemerkt habe, dass Microsoft in C# mittlerweile eine spezielle Delikatesse namens “Extension Methods” anbietet. Das sind Methoden, die sich mehr oder weniger automatisch an Instanzen bestimmter Klassen hängen und so tun, als wären sie Teil der Klasse. Ja, das ist gewissermaßen AOP Deluxe: Die gesamte Verwirrung und Unverständlichkeit der AOP, nur nicht so mächtig wie AspectJ oder vergleichbare S/M-Technologien. Genial, das muss ich in Zukunft in jedem einzelnen Stück Code verwenden, von dem ich sicher weiß, dass es zukünftig nur von anderen gepflegt werden muss, nicht von mir selbst.

Ah, fast vergessen - einen Link gibt es ja auch noch: Extension Methods bei MSDN. Go and knock yourselves out.

So oder ähnlich denkt man, wenn man a) zuviele Folgen der Golden Girls gesehen hat und b) gerade mit .NET arbeitet. Zumindest dann, wenn man gerade folgende Situation hatte:

• Ein WebPart enthält einen GridView mit einer ObjectDataSource, die auf ein eigenes DAL verweist
• Das Part funktioniert in ASP-Seiten
• Das Part funktioniert im Sharepoint mit voller Pulle Trustlevel
• Das Part fliegt mit einem Hinweis, dass die DAL-Klasse nicht gefunden wurde, auseinander, wenn man es im GAC installiert.

Des Rätsels Lösung war ganz einfach, wenn man nur weiß, wo man suchen muss. Wir hatten diesen Code (den ich aus einem Tutorial kopiert hatte) im Part:

ObjectDataSource ods = new ObjectDataSource();
ods.EnablePaging = true;
ods.SelectMethod = “getItems”;
ods.SelectCountMethod = “GetTotalItemCount”;
ods.SortParameterName = “sortExpression”;
ods.TypeName = typeof(AreDal).ToString();

Die letzte Zeile musste wie folgt geändert werden, damit das Mistding vernünftige Klassennamen mit Assembly-Namen und Public-Key-Dingsbums ausspuckt:

ods.TypeName = typeof(AreDal).AssemblyQualifiedName;

NA DANN! Wieso ist das ToString bei dem Mist eigentlich nicht gleich so implementiert, dass es ordentlich funktioniert? Kann mir das irgendwer verraten? Nein? Naja, auch egal, ich hab’s ja jetzt.

Ganz einfach, man gibt den Port einfach in der DB-URL an, also typischerweise so:

hostname.domain.de:4711\InstanzName

Nein, natürlich nicht. Das wäre ja die Standardnotation, und bekanntlich mag Microsoft keine fremden Standards. Den abweichenden Port muss man deshalb mit einem KOMMA trennen, nicht mit einem Doppelpunkt… Der korrekte Hostname sähe also so aus:

hostname.domain.de,4711\InstanzName

Ja, leckt mich doch… Bis ich das raus hatte, hatte ich mal wieder eine ganze Reihe neuer grauer Haare. Die Rechnung für das Haarfärbemittel schicke ich auf jeden Fall an Microsoft, Abteilung “Anwenderverwirrung”.

Nix “wuppwupp”. Mein Projekt wollte eine signierte Assembly (”strong-named”, wie wir Experten das nennen) bauen, aber leider war die DatePicker-Assembly nicht signiert. Arglgnagnabarfzgna. Da stand ich dann also und durfte mich fragen, was und warum und wie und ob ich jemals wieder Java benutzen darf.

Manche Probleme sind zum Glück nicht ganz so gravierend, wie sie zunächst aussehen. Als elitärer Google-Master bin ich nämlich auf einen Blogpost gestoßen, der eine ganz einfache, wenn auch etwas hackerige Lösung enthielt:

ildasm /tokens /out=unsignedAssembly.il unsignedAssembly.dll
ilasm /dll /key=key.snk unsignedAssembly.il /out=signedAssembly.dll

Die Assembly zu disassemblieren und dann wieder zusammenzuklatschen ist zwar irgendwie leicht gewagt - aber was kratzt mich das, solange es nur funktioniert? Nicht die Bohne, genau.

Ich brauchte für eine Dropdown-Liste die Werte eines enum-Typen, was ziemlich Easy ist: Man kann jedes enum-Dings einfach nach int casten, schon hat man was, was man in ein Dropdown frickeln kann. Das sieht etwa so aus:

myListBoxDings.Items.Add(FrickelEnum.Burfz.toString(),  ((int)FrickelEnum.Burfz).toString());

Yep, ganz easy. Blöderweise musste ich jetzt aber den Wert aus der Liste in eine andere Methode stopfen, und die erwartet als Parameter keinen string, kein int, nein - einen enum-Wert. Gnarfzgagagagaga. Damenunterhose. “Microsoft! Microsoft!”

Was für versierte .Net-Profis (erkennbar an der Damenunterbekleidung) kein Problem ist, hat mich erstmal ziemlich genervt, bis eine kleine Google-Recherche gezeigt hat, dass das alles kein Problem ist, solange man nur weiß, wie es geht:

FrickelEnum brunf = (FrickelEnum)Enum.ToObject(typeof(FrickelEnum),  Int16.Parse(myListBoxDings.SelectedValue))

Ha! Geht doch! Damit kann ich mich jetzt der eigentlichen Logik widmen und schon mal über den nächsten Artikel nachdenken, der den Titel “WCF ist Microsofts Version von WTF?!?” tragen wird. Ob dieser jemals geschrieben wird, hängt allerdings wohl davon ab, wie meine Chefs zur Frage des Beschäftigungsverhältnisses für nackte Entwickler mit Tangas auf dem Kopf stehen. Microsoft! Microsoft!

(Falls es jemand wissen will: Das Ergebnis der besagten Google-Recherche war dieser hilfreiche Artikel hier.)

Der Moment, an dem es mit diesem schönen Freitag massiv bergab ging war der, in dem ich ein Custom Control bauen wollte, welches in einem Web Part eingebunden werden sollte und in dem eine Tabelle mit Werten angezeigt werden sollte - ein GridView, wie wir Möchtergern-Experten es gerne nennen. Weil die Applikation ja sauber aufgebaut ist, konnte das seine Daten nicht direkt aus einer SQLDataSource holen sondern aus einer selbstgebauten DataTable. Das ging sogar, doch beim Klick auf einen der Sortierlinks in der Titelzeile flog alles auseinander. Zwei Stunden später wusste ich immer noch nicht, wieso der Kram nicht sortieren wollte und der Tag war dort, wo vorher die immer noch ziemlich sprichwörtliche Sonne herauszuscheinen beliebte.

Weitere zwei Stunden später ging die Sonne wieder auf, denn ich hatte ein sehr hilfreiches Forenposting über GridView, DataTable und die verdammte Sortierfunktion gefunden. Ein wenig kopierter Code, und schon konnte ich sortieren. Aufsteigend. Andersrum nicht, wieso auch immer.

Also tat ich, was ich gleich hätte tun sollen, und las besagtes Posting etwas weiter, nämlich bis zu dem Punkt, wo andere mein Problem hatten und der ursprüngliche Auto sich erbarmte, nochmal nachzuarbeiten - das Ergebnis dieser Nacharbeit findet man auf dieser Seite hier, allerdings rafft man es nicht, ohne das Posting gelesen zu haben. Macht nix, zur Not reicht kopieren ohne Peilung auch aus - solange das GridView nur sortiert.

Fazit 1: Du sollst das Control nicht vor dem GridView loben.

Fazit 2: DataTables lassen sich nicht ohne fremde Hilfe sortieren.

Fazit 3: Ich gehe jetzt heim, bevor ich noch auf die Idee komme, meinen Fileupload zu testen…

Gut, mit der microsoften Version des Minerals ist man scheinbar noch nicht ganz so weit, wie es in der Java-Welt der Fall ist, und auch eine passende Integration in Spring.net scheint es noch nicht zu geben, aber so weit ich es aus dem Tutorial erkennen kann, ist die Entwicklung auf jeden Fall weit genug, um einen Test zu rechtfertigen. Falls man mal unter .Net schedulieren muss natürlich, ansonsten kann man seine Zeit sicher mit angenehmeren Beschäftigungen totschlagen.

Gerade als Umsteiger aus der Java-Welt habe ich allerdings ein paar Stolpersteine gefunden, die nicht ganz ohne sind. Der grundlegendste dieser Steine war wohl die Sache mit dem Lifecycle der ASP-Seiten - ich dachte ganz arrogant, dass ich das als erfahrener J2EE-Anwender schon intutiv raffen würde, und das war ein Irrtum. Irgendwie wurde aber schnell alles klarer, als ich die kurze Einführung in den Lebenszyklus einer ASP-Seite durchgelesen habe, die mir MHenze freundlicherweise empfohlen hat. Wer hätte gedacht, dass in so wenig Text so viel Lebensrettungspotenzial stecken könnte?