OK, ich kriege nicht wirklich Komplexe, weil ich immerhin in der Lage bin, sowohl das Problem als auch den Lösungsansatz zu begreifen - nur komme ich mir irgendwie minderwertig vor, weil ich noch nie ein Problem hatte, das so einen wunderbar abstrakten, abgehobenen und irgendwie erregenden Lösungsweg erfordert hätte. Es sieht so aus, als müsste ich mir dringend ein paar ausgefallene Probleme, einen abgefahrenen Akzent und einen Satz wirklich feiner Ideen besorgen, um mich selbst wieder richtig ernst nehmen zu können.

Ach ja, einen direkten Link zur Projektpage von Kilim kriegt Ihr natürlich auch noch. Ich bin ja nicht so.

Das Projekt von damals ist ziemlich gewachsen, inzwischen gibt es APIs für Android, normales Java und JavaScript - eine Version für Windows Mobile ist auch schon angekündigt. Ich hatte jetzt noch nicht wirklich die Gelegenheit, mir das alles im Detail anzusehen, aber die Entwickler-Website von ALOQA macht schon mal einen sehr guten Eindruck. Es scheint viel Doku zu geben und Beispiele habe ich auch gesehen - was will man mehr? Eine geeignete Lizenz vielleicht noch, aber die gibt es nach Aussage meines Kontakts scheinbar auch. Ich zitiere:

Alle Schnittstellen und Softwaremodule können gemäß den Nutzungsbedingungen in einem bestimmten Rahmen kostenlos verwendet werden, solange der entwickelte Dienst / die mobile Anwendung Endnutzern kostenlos zur Verfügung steht.

Klingt nicht verkehrt. Muss ich mir gelegentlich näher ansehen.

Falls jemand mal das „Vergnügen“ haben sollte, eine Webanwendung auf einem Server eines der ganz großen deutschen Hoster zu betreiben und die PHP-Sessions mit ihm Lotto spielen sollten (das muss man auch erstmal merken), dann erspart Ihr Euch mit folgender Zeile in einer eigenen php.ini evtl. wertvolle Freizeit, erhaltet Eure Nerven und könnt die gewonnene Zeit für ein leckeres Bier nutzen:

session.save_path=/home/strato/www/<first-two-letters-of-domain>/<domain>/htdocs/sessions

Der Fehler ist nie wirklich reproduzierbar und die „aktive“ Session wird anscheinend mit dem ganz großen Würfel bestimmt. Meine Spekulation wäre ja, dass das /tmp Verzeichnis des Servers einfach voll ist (Anzahl Filehandles oder auch Inodes). Was aber doch verwunderlich ist, ist dass das dann keinen Fehler schmeisst, sondern scheinbar toll funktioniert… nur eben mit einer Zufalls-Session.

Uuh, klingt ungroovy, also gar nicht tofte. Vor allem würde ich das für einen dieser Fehler halten, die einen mangels Reproduzierbarkeit ganz locker in klinische Zustände treiben können, und das muss ja nicht sein.

Du solltest Dir unbedingt mal SDL ansehen, das wird Dir gefallen.

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.

Dank PRogalinski ist der Schmerz zumindest bei der ASP-Konfickelei jetzt aber etwas weniger schlimm, denn er hat mir das web.config-Editiertooldings “ASPHere” gezeigt, von dem ich ziemlich begeistert bin. OK, ich habe es nur mal kurz ausprobiert, aber meine vorhandenen Dateien konnte es einlesen und bearbeiten, ohne Fehler zu spucken - das ist ein gutes Zeichen.

Besonders fein finde ich bei dem Tool noch nicht mal unbedingt, dass man visuell configgen kann, sondern dass man eine übersichtliche Liste der möglichen Optionen nebst Hilfestexten, Tooltips und Links zu MSDN hat. Meistens ist es schließlich gar nicht so arg schwer, den Kram hinzuschreiben - nur weiß man halt von den meisten Optionen gar nicht, dass es sie überhaupt gibt, und da hilft so ein Optionsbrowser doch enorm. Wer sich mit ASP rumschlagen muss, sollte jedenfalls mal einen Blick auf das Dings werfen.

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.