René's Weblog und was die Welt noch nicht wissen wollte

HTTP Compression nutzen

weblog@drescher-hackel.de (René Drescher-Hackel) — Thu, 10 Jun 2010 07:47:34 GMT

Wer den Fiddler2 in Benutzung hat und sich diverse Auswertungen ansieht, stolpert sicher so wie ich über die Anzeige der Kompression der Webseite.

Also stellte sich die Frage, wie ich nun diese Kompression aktiviert bekomme. Auf den Internetseiten von Microsoft findet man diverse Hinweise, wie das ganze sich am IIS einstellen lässt.

Irgendwie habe ich es aber nie geschafft, auch nur annähernd das angezeigt zu bekommen, was in den Beschreibungen genannt wurde.

Nun fand ich eine weitere interessante Lösung.

Hier wurde beschrieben, wie sich die Kompression über die Webanwendung realisieren lässt. Dazu wird in der Datei global.asax einfach die Methode Application_PreRequestHandlerExecute(object sender, EventArgs e) implementiert.

Was passiert dann in dieser Methode: zuerst wird über den Header ausgelesen, ob Kompression überhaupt unterstützt wird. Je nach dem, welche Unterstützung gegeben ist, wird der aktuelle OutputStream entsprechend komprimiert und wieder an die Response.Filter - Eigenschaft übergeben.

Den Code kann man auf der o.g. Webseite nachlesen.

Implementiert man das Ganze, wie beschrieben, bleibt der Erfolg nicht aus und Fiddler2 zeigt an, dass die Komprimierung der Webseite aktiv ist.

Eine weitere Überprüfung mit Firebug bestätigt die Anzeige.

Es ist doch am Ende immer wieder schön zu erleben, wie einfach die Dinge sich lösen lassen.

Gedanken zum Test Driven Development (TDD)

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 27 Mar 2010 23:57:14 GMT

Am 25.03.2010 hat die Franken-.NET-Usergroup das Thema TDD auf der Tagesordnung gehabt. Grund genug, sich auf den Weg von Regensburg nach Erlangen zu machen.

Mein Fazit ist jedoch relativ nüchtern ausgefallen. Doch der Reihe nach. TDD gehört inzwischen zum guten Ton unter Softwareentwickler, genauso wie CCD und OOP/OOD. Doch bringt mich TDD wirklich weiter? Bin ich wirklich effektiver am Ende?

Hier habe ich nach dem Vortrag meine Bedenken. So war eine Aussage: „Ohne ReSharper geht’s gleich gar nicht“ Hallo? Habe ich was verpasst? Es kann ja wohl nicht allen Ernstens davon abhängen, dass ich ReSharper einsetzen muss, um gescheit zu entwickeln! Deutlich ist dann auch geworden, dass in der Tat ein Refactoring der implementierten Codezeile vom Vortragenden fast ausschließlich auf „Anraten“ des ReSharper erfolgte. Irgendwie erinnert das Ganze mich an den immer noch andauernden Handy-Wahn. Fast kein Mensch ist heute noch ohne Handy unterwegs, man muss immer erreichbar sein, die wenigsten schaffen es, das Telefon auszuschalten. Mit dem Re-Sharper scheint ein ähnliches Phänomen bei den Softwareentwicklern angekommen zu sein. Um es gleich deutlich zu machen – ReSharper ist sicher ein sehr gutes Programm, dass seine Dienste tut – aber wenn ich dann nur noch offensichtlich in der Lage bin, Code gescheit aufzuräumen, wenn Fremdsoftware mich dabei unterstützt, dann finde ich es schon etwas traurig, wohin die Entwicklung geht. Doch damit nicht genug – komme ich zurück zum TDD und die Eingangs gestellt Frage: bin ich wirklich produktiver? Jan Welker erklärte gleich zu Beginn des Vortrages, dass ihnen bei der Vorbereitung aufgefallen ist, dass sie nach einer Stunde intensives „coden“ nicht einmal F5 gedrückt haben – sicher fein, aber wie oft haben sie ihre Test gestartet?? Der Abend schaffte Klarheit – überspitzt formuliert: für jede Zeile Code ein Teststart (analog F5). Im anschließenden Gespräch räumte Jan ein, dass man in der Tat wesentlich öfter die Tests startet, als man es sonst mit dem beherzten Tastenanschlag der F5 Taste täte. Na prima, bleibt das Denken nun auf der Strecke?

Ist es denn nicht so, dass ich mir vorher Gedanken mache, was ich für mein Programm implementieren möchte? Tests helfen mir in der Regel, wenn ich mein Programm erweitere und durch meinen Testlauf sicher gestellt werden kann, dass bestehender Programmcode noch weiter funktioniert. Aber eigentlich ja auch wieder der falsche Ansatz, weil dann würde ich im Code erweitern und nicht wie in der TDD vorgesehen, von der bestehenden Testmethode aus, also testgetrieben. Aber brauche ich einen selbst kreierten Kontrolleur meiner Arbeit? Sinnvoll ist das TDD doch erst dann, wenn die Testmethoden von einem Dritten erstellt werden und nicht vom Programmierer selbst. Wenn der Entwickler den Test formuliert, dann sehe ich auch hier die Gefahr, dass die Tests nur soweit formuliert werden, wie das Verständnis des Programmierers für die geforderten Funktionalitäten am Ende sind. TDD soll mich dazu anhalten, nur das zu implementieren, was auch tatsächlich benötigt wird – aber mal ganz ketzerisch gefragt: machen wir das nicht immer?? Jetzt steht auf der anderen Seite CCD mit seinem „Anspruch“, dass wir gut sortiert und aufgeräumten Code schreiben, der auch noch nach Wochen lesbar und verständlich ist. Das gleiche Ziel verfolgt aber TDD auch -> YAGNI.

Im Rahmen des Treffens kamen dann noch Fragen auf, ob man nicht auch „private“ Methoden Unit-Tests unterziehen kann. Das Ganze entwickelte sich dann plötzlich in eine weitere überraschende Richtung, in dem Tom den Einwand erhob, doch bitte nur gegen Interfaces zu programmieren und nur das, was öffentlich bekannt sein soll, eben über ein Interface bereit zu stellen. Oh je, dachte ich so bei mir. Also private Methoden muss ich nicht separaten Tests unterziehen, denn der Ansatz der TDD ist ja gerade, dass ich von einer Methode her implementiere, teste und dann aufräume. Im Zuge des Aufräumens entstehen meine privaten Methoden. Da der Test vorher gelaufen ist, brauch ich also die neu entstandenen Methoden eben nicht mehr separaten Tests unterziehen.

Die Frage, die sich mir nun stellt ist, wie geht es weiter? Der derzeitige Status Quo ist für mich etwas verwirrend. Was mir fehlte an diesem Abend ist die Testautomation mit Visual Studio. Ich verstehe nicht, warum ich nicht die Testmöglichkeiten des Studios nehme. Gut, einzig das Argument, dass Tests im Studio erst mit der Professional-Version von Haus aus möglich sind, würde die Vorgehensweise, wie sie am Abend besprochen wurde rechtfertigen.

Die meisten Probleme, die in der Entwicklung auftreten, betreffen in der Regel Fragen des Integrationstest. Ich persönlich sehe nicht die Probleme in der Entwicklung, dass ich mich von TDD abhängig mache. Sicher ist die Vorgehensweise, vom Test zum Code zu entwickeln, von Vorteil – doch sehe ich darin kein Allheilmittel. Fragen des Integrationstest, Fragen des Tests von mit einander verbandelten Komponenten sind offen geblieben.

Geht nicht - gibt's nicht

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 06 Mar 2010 14:27:35 GMT

Im dotnet-magazin 4/2010 habe ich mich mal mit dem Thema der Auswahl von Komponenten auseinander gesetzt. Das Magazin ist seit dem 03.03.2010 im Handel zu erhalten.

Generische Session

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 23 Jan 2010 20:40:15 GMT

In Ergänzung zum Blogbeitrag Session einmal anders verwalten könnte man doch das ganze um eine generische Methode erweitern, so dass man nicht mehr das anschließende Casten des Sessionrückgabewertes vornehmen muss. Im Folgenden zeige ich kurz, welche Änderungen hierzu erforderlich wären.

Die statische Klasse AppSession wird um eine generische Methode Get<T> erweitert.

Da das Session-Objekt und der Enum SessionKey jeweils um die Get-Methode erweitert wurden, muss auch der generische Ansatz hier implementiert werden, wobei dann wie gehabt die generische Get<T>-Methode der AppSession-Klasse aufgerufen wird.

und

Eine Frage, die schnell beim debuggen autauchen kann, warum denn nun eigentlich casten, wenn im Watch-Fenster über GetType immer der richtige Type angegeben wird. Man möchte doch meinen, dass doch alles korrekt ist.

Doch Vorsicht ist geboten - die Erkenntnis ist dann gewiss, möchte man mit dem Objekt arbeiten:

Mit der generischen Implementierung kann ich sofort auf dem Objekt arbeiten und Werte modifizieren,

was ich in der klassischen Variante nicht kann.

Berechtigter kritischer Einwand - auf null muss so oder so geprüft werden.
Statt auf dem Sessionobjekt, könnte man die gleiche Implementierung auch auf dem Applicationobjekt umsetzen.

Update ohne Panel mit AJAX.PRO

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 22 Nov 2009 21:30:27 GMT

Kürzlich stolperte ich über einen Beitrag von Roberto Bez, als ich dabei war, einen Blogbeitrag zum Thema Updatepanel & Co zu planen. Es entspricht dabei einer alten Angewohnheit, dass ich zuerst einmal schaue, ob nicht über dieses Thema schon genug geschrieben wurde, oder ob möglicherweise ein Bedarf da ist. Gut, ich muss eingestehen, zum Thema welches sich mit Ajax.Pro realisieren lässt gibt es im Netz in der Tat nicht viel - im Wesentlichen ja nur Michaels Seite.

Aber zurückkommend auf das eigentliche Thema - dem Updatepanel - da ist immer genug Zündstoff vorhanden. Und so haben sich schon Roberto und Kristof Zerbe mit dem Thema im Rahmen einer jQuery-Plugin-Entwicklung recht eindrucksvoll befasst. Ich möchte mich heute einer weiteren Variation zu dem Thema zuwenden, natürlich unter Verwendung von Ajax.Pro und etwas Javascript.

Hinsichtlich der grundsätzlichen Fragen zu Ajax.Pro sei zunächst auf die Seite von Michael Schwarz verwiesen als auch den Blogbeitrag, welchen ich hierzu schon einmal verfasst habe. Prinzipiell muss an dieser Stelle gesagt werden, Ajax.Pro ist nicht mehr kompliziert, als die Umsetzung des Ganzen über jQuery und Webservices. Ich halte hier Ajax.Pro sogar noch für wesentlich einfacher, da ich als Entwickler mich auf das Wesentliche konzentrieren kann und der Implementierungsaufwand meiner Meinung nach sogar noch geringer ausfällt. Zudem bietet mir Ajax.Pro die Möglichkeit, .NET-Objekte an den Client zusenden - doch dazu weiter unten mehr.

Zurück zum Updatepanel: seit je her waren in der Webentwicklung Bestrebungen da, möglichst nur Teilbereiche der Seite zu aktualisieren und nicht immer die ganze Seite neu zu laden. Die Anfänge waren wohl die Frames. Dann kamen die IFrames, dann das Remotescripting und ActiveX und nun sind wir beim XmlHttpRequest.

Für den Benutzer der Webseite als auch den Entwickler ist das Manko des Updatepanels aber offensichtlich - es wird jedes Mal der komplette Page-Lifecycle durchlaufen - ganz dem Motto: "Kauf eine Kuh, wenn du ein Glas Milch brauchst". Aber das war es doch eigentlich, was mit AJAX alles besser werden sollte? Nun gut.

Was passiert in der Regel, wenn man sich für das Updatepanel entscheidet: in der Regel lädt der Entwickler ein Usercontrol wodurch die Seite im Informationsgehalt sich ändert. Das Usercontrol ist dabei meistens ein HTML-Ausschnitt, also nie eine HTML-Seite im eigentlichen Sinne. Was der Entwickler dann in der Regel ebenfalls macht - er lädt die Daten, die für den Benutzer von Bedeutung sind gleich mit. Und da haben wir schon das eigentliche Problem. Letztlich ist doch genau diese Vorgehensweise schlichtweg blöd. Denn was habe ich immer: ich habe immer eine unbekannte Menge an Benutzern denen ich aber allen zum Beispiel immer das gleiche Formular präsentiere. Ist es denn nicht sinnvoller schon an dieser Stelle Daten und Anzeige zu trennen? Roberto und Kristof haben es ebenfalls in ihren Beiträgen klar herausgestellt: JSON ist das, worauf man sich hier konzentrieren sollte. Wenn ich die Daten, welche regelmäßig einen benutzerspezifischen Hintergrund haben, von der Anzeige löse, dann kann ich die Anzeige viel besser cachen. Dem könnte man jetzt kritisch entgegnen, dass man zusätzliche Serveranfragen hat oder, wenn man die Daten holt, kann man das Layout doch auch gleich mitnehmen. Nun, ja, man kann. Aber ich möchte hier letztlich demonstrieren, dass man es auch anders lösen kann. Den Vorteil, welchen ich in dieser Lösung sehe ist schlichtweg, dass ich mich auf das Wesentliche konzentriere - dem Datenaustausch. Damit schaffe ich langfristig eine deutliche Verringerung des Datentransfers in der Client-Server-Kommunikation.

Bei meiner Planung von Webanwendungen mit Ajax-Funktionalität setze ich auf Ajax.Pro. Wie oben schon gesagt, ist es in meinen Augen wesentlich übersichtlicher und der Implementierungsaufwand ist auch deutlich geringer. Dies möchte ich kurz an Hand einer kleinen Gegenüberstellung verdeutlichen:

Roberto und Kristof haben sich für jQuery und folgenden Aufbau entschieden:

Über einen Defaultparameter wird ein Standardusercontrol benannt und im Weiteren werden die für die jQuery-Implementierung eines Ajax-Aufrufes erforderlichen Parameter und Einstellungen gesetzt.

Mit Ajax.Pro würde ich die Umsetzung zum Beispiel so umsetzen:

Worin unterscheiden sich die beiden Ansätze? Bei Ajax.Pro muss ich mich nicht mehr um den dataType und den contentType kümmern. Dies wird von Ajax.Pro automatisch gesetzt, entsprechend dem zurückgegebenen Types. Würde ich mich hier bei der jQuery-Lösung verschreiben, hätte ich ein Problem. Weiter muss ich nicht die Architektur offen legen. Mit Ajax.Pro könnte ich sogar die Methodennamen per Attribute nach außen verschleiern. Da meine Templates allesamt namentlich bekannt sind, habe ich hier einen Enum angelegt, den ich beim Aufruf der Servermethode einfach mitgebe. Den Rest, wo zum Beispiel das Usercontrol am Server liegt, das alles kann ich über den Enum serverseitig auflösen. Und zu guter Letzt - ich habe deutlich weniger Schreibaufwand.

Hinsichtlich des Ladens des Usercontrols, so dass es gerendert werden kann, hat Kristof aus meiner Sicht die bessere Lösung gewählt. Generell ist es immer das gleiche Vorgehen: Eine Instanz der Page-Klasse wird erzeugt. Über die statische Methode LoadControl der Page-Klasse wird das Usercontrol geladen und dem zuvor erzeugten Instanzobjekt hinzugefügt. Über die Excecute-Methode des Server-Objekts des aktuellen HttpContexts wird die Pageinstanz in ein Stringwriter-Objekt übertragen und das Stringwriter-Objekt über die Methode ToString an den Aufrufer zurückgegeben.

Würde man dies so belassen, hätte man das Problem, dass das Usercontrol keine ASP-Server-Steuerelemente beinhalten dürfte. Man wäre auf Standard-HTML-Elemente beschränkt und könnte so zum Beispiel auch keine Customcontrols im Usercontrol unterbringen.

Kristof hat diesen Punkt in seiner Variation des jQuery-Plugins des ascxLoader mit berücksichtigt und fügte dem Page-Instanzobjekt noch eine Form-Instanz hinzu. Bevor er Stringwriter an den Aufrufer zurückgibt, bereinigt er diesen, in dem er den Form-Tag und den Viewstate unter Verwendung eines regulären Ausdrucks aus der Zeichenkette entfernt.

Die o.g. Methode würde abschließend daher so ausschauen:

Anders als Kristof löse ich das Entfernen des Viewstate und des Form-Tags auf der Clientseite. Man könnte es aber genauso gut auf der Serverseite lösen, so wie es Kristof über reguläre Ausdrücke gemacht hat, was dann den Vorteil hätte, dass man weniger Daten am Ende über die Leitung schickt. Meine clientseitige Lösung sieht indes so aus:

Ich erzeuge als erstes ein jQuery-Objekt. Anschließend suche ich den DIV-Tag, der ein input-Element enthält, dessen ID-Attribute den Wert VIEWSTATE beinhaltet. Zum Schluss übernehme ich dann aber nur den innerHTML-Teil des Form-Tags.

Soweit so gut. Eingangs hatte ich angesprochen, dass es doch von Vorteil wäre, man würde beim Usercontrol eine weitere Abstraktion vornehmen, indem man das reine Layout von den benutzerspezifischen Daten noch einmal trennt. Das hat dann den Vorteil, dass ich einmal vom Server abgerufenes Layout sowohl am Server als auch am Client zwischenspeichern kann. Das Beispielprojekt, welches ich zu diesem Beitrag angelegt habe, beinhaltet einen Container, der über einzelne Tabreiter gesteuert wird. Für jeden Tabreiter wird ein individuelles Layout vom Server abgerufen. Wechsle ich nun zwischen den Tabreitern in völliger Aufregung hin un her (diese Leute gibt es wirklich, die sowas machen - ich hab sie kennen gelernt), dann muss ich nicht dauernd den Server bemühen, sondern kann auf die im Javascript gecachten Daten zurückgreifen. Der Performancegewinn ist dabei enorm.

Möchte ich nun die Formularelemente mit Daten füllen, so sende ich nur noch ein Minimum an Daten zwischen Client und Server hin und her. Gerade bei recht komplexen Formularen erscheint mir dieses Vorgehen recht sinnvoll.

Auch auf der Serverseite kann man einmal erledigte Arbeit so abspeichern, dass alle Benutzer einen Vorteil davon haben. So habe ich mich entschlossen, jedes erstmals gerendertes Usercontrol in einer Applicationvariable abzulegen.

Betrachte ich jetzt den Punkt des Datentransfers, so sollte man sich zu jedem Usercontrol eine Objektstruktur überlegen, über die man zwischen Client und Server die Daten austauschen kann. Roberto hat in seinem Beitrag die Möglichkeit des Austauschs komplexer Objekte angesprochen und eine Lösungsmöglichkeiten aufgezeigt. Ajax.Pro bringt diese Möglichkeit gewissermaßen von Haus aus mit - ein Umstand, den ich von Beginn an sehr geschätzt habe und auch heute nicht mehr missen möchte. In diesem Zusammenhang möchte ich auf das Beispielsprojekt zu meinem o.g. Blogbeitrag nur verweisen.

Im heutigen Beispiel übertrage ich zwischen Client und Server lediglich einen String. Das Ganze ist soweit ohnehin noch recht ausbaufähig. Im wesentlichen möchte ich ja nur die prinzipielle Möglichkeiten aufzeigen.

Als Datenquelle habe ich wieder eine kleine XML-Datei genommen, welche einen Ausschnitt aus der Customer-Tabelle der Northwind-Datenbank wieder gibt. Als Contenttemplates habe ich zwei Usercontrols angelegt, welche ich zusätzlich über einen Enum verwalte.

Das Rendern der Usercontrols speicher ich mir in einer Applicationvariable ab, so dass diese Arbeit nur einmal getan werden muss. Auch hier ist wieder Spielraum, wie man die Verwaltung der Templates, wenn sie gerendert sind, aufbauen möchte.

Clientseitig werden die Template nur vom Server geholt, wenn sie noch nicht im Array, welches ich als Clientcache benutze, vorhanden sind. Im Ergebnis muss ich mich nur noch um die Daten kümmern. Hierzu habe ich mir eine kleine Methode geschrieben. Der Kniff besteht am Ende darin, dass die Formularfelder die gleichen Namen haben, wie die Objekteigenschaften des Datenobjektes.

Der Klick auf den Link in der Listenansicht wird über den eventgebundenen Container aufgelöst. Einen sehr ausführlichen Blogbeitrag zu dem Thema der Eventsteuerung hat Michael Schwarz verfasst. Für den Fall, dass das Template für die Listenansicht geladen ist, wird der Datensatzkey zwischengespeichert und anschließend programmatisch der Tab für die Detailansicht aufgerufen.

Jetzt beginnt das Prozedere wieder von vorn - das Template wird geladen (vom Server oder aus dem Clientcache) und zu guter Letzt die Daten entsprechend dem zwischengespeicherten Datensatzkey vom Server abgeholt. Die Daten selbst könnte man nun auch am Client zwischenspeichern, doch müsste man hier unbedingt noch ein Zeitfenster berücksichtigen, wann die Gültigkeit der gecachten Daten verfällt. Beim reinen Formular hat man indes diese Sorgen nicht, da es hier in der Regel an den Daten fehlt.

Das zum Download bereitgestellt Projekt ist ein Visual Studio 2008 Projekt.

Live-Demo: (einen Tab anklicken)

Detail
Liste

Lade Daten...

Zusammenfassend lässt sich also sagen, dass sowohl über die von Roberto und Kristof aufgezeigten Wege Usercontrols bequem über ein Ajax-Request nachgeladen werden können, als auch über Ajax.Pro sich das Ganze umsetzen lässt.

Ein weiterer Punkt, der ebenfalls vorher geklärt sein sollte - will man denn in der Form Usercontrols nachladen - ist die Anwendungsstruktur. Es will sehr gut überlegt sein, wie die ganze Webanwendung aufgebaut sein soll und wie sie arbeiten soll.

Viel Spaß beim Ausprobieren

Tücken im asynchronen Datei-Download

weblog@drescher-hackel.de (René Drescher-Hackel) — Tue, 17 Nov 2009 10:40:25 GMT

Gelegentlich kommt es vor, dass man über seine Webanwendung, Dateien zum Download bereitstellen möchte. Knifflig wird's allerdings dann, wenn AJAX mit im Spiel ist. In diesem Beitrag möchte ich kurz aufzeigen, über welches Problem man dabei stolpern kann.

AJAX-Anwendungen sind bekannt dafür, dass man bestimmte Prozesse zwischen Client und Server ablaufen lässt und dies in der Regel so gestaltet, dass der Client nicht unnötig in seiner Arbeit blockiert wird. Das Ganze ist als asynchroner Prozess bekannt.

Eine Datei zum Download anzubieten ist von der Sache her auch kein großes Problem: in der Regel wird hierzu ein Http-Handler bemüht, der den Filestream an den Ausgabestream des Response-Objektes übergibt. Über die AddHeader-Methode kann man angeben, dass die Datei zum Download bereitgestellt werden soll.

Soweit also alles kein Problem. Interessant wird es dann, wenn dem eigentlichen Download eine Anfrage zum Server vorausgeschaltet ist, um zum Beispiel zu erfassen, wie oft die Datei heruntergeladen wurde, der eigentlich Download der Datei aber im Callbackhandler initiiert wird. In diesen Fällen passiert im Internet Explorer folgendes:

Dies ist dann doppelt ärgerlich, wenn die Webanwendung ihren Inhalt asynchron nach lädt. Bestätigt man nun die Warnmeldung des Internet Explorers, dann ist der ursprüngliche Content verworfen, da ein vollständiger Reload der Seite erfolgt. Wie kann man das Problem nun umgehen? Ganz klar - man liest sich die Informationen der Informationsleiste genau durch, wo es nämlich heißt:

Im Ergebnis bedeutet dies, im Fall der dem Download vorausgehenden Serverkommunikation muss diese synchron erfolgen, damit der Kontext der Verarbeitung nicht unterbrochen wird.

Beispiel: (Download einer einfache Textdatei - sampleDownload.txt)

synchron | asynchron

Die gleiche Problematik tritt auf, wenn innerhalb einer setTimeout-Anweisung ein Dateidownload angeboten wird. Ebenso ist klar, dass diese Problematik nur zutrifft, wenn der Download der Datei über Javascript veranlasst wird.

SEO - Suchmaschinenoptimierung

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 16 Nov 2009 17:09:51 GMT

SEO - eine Abkürzung nur oder ein Konzept, welches man ernst nehmen sollte? Hinter SEO verbirgt sich letztlich nichts anderes als die englische Bezeichnung Search Engine Optimization, die im Deutschen für Suchmaschinenoptimierung steht. Es stellt sich jedoch die Frage, wie optimiere ich meine Webseite für die gängigen Suchmaschinen. Auf diese Fragen möchte ich im folgenden einmal etwas näher eingehen.

Es ist wohl relativ unbestritten, dass Google als Suchmaschine eine wichtige Rolle in unserem Internet-Leben spielt. Es vergeht nahezu kein Tag, wo im Radio oder im Fernsehen nicht eine Meldung zum Thema Internetrecherche zu vernehmen ist. Auch haben die Zeitungen erkannt, dass es nicht ohne (Medium Internet) geht. Darum ist es wichtig, gut und schnell gefunden zu werden, damit die angebotene Information nicht in der Flut an im Internet abrufbaren Informationen untergeht.

Andere Suchmaschinenanbieter wie Yahoo oder Bing bieten ähnliche Programme an, doch möchte ich mich in diesem Beitrag auf die Webmaster-Tools von Google beschränken. Wie gesagt - sie kochen letztlich alle nur mit Wasser, die grundsätzlichen Informationen für eine gute Suchmaschinenoptimierung sind aber am Ende für alle nahezu gleich.

"Wie unterstützt mich eine Suchmaschine?" Diese Frage sollte man sich als erstes stellen, selbst wenn die Seite sich noch im Aufbau befindet. Wer sich bei Google registriert, kann hier die Webmaster-Tools nutzen.

Wie die Webmaster-Tools funktionieren, hat Google separat in einer Anleitung zusammen gefasst. Was allerdings noch zu beachten ist, findet man bei Google in einer weiteren Hilfestellung oder man beherzigt schlichtweg die Hinweise, die man bei Wikipedia findet.

So nützt es recht wenig und kann schlimmstenfalls zur Sperrung der Seite im Suchmaschinenindex führen, schaltet man vor der eigentlichen Seite eine weitere Seite mit Suchbegriffen oder Schlagworten (die am Ende auch wenig mit dem Inhalt der eigentlichen Seite zu tun haben). Ich habe auch schon Seiten gesehen, die hatten einen ausgeblendeten DIV-Container auf der Seite, gespickt mit gängigen Begrifflichkeiten. In den Anfängen des Internet war ebenso beliebt, die META-Tag für diverse gängige Suchbegriffe zu missbrauchen. Die Suchmaschinenbetreiber haben dies schnell erkannt und reagiert. Und so verwundert es nicht, wenn man dann in Googles Richtlinien liest:

Erstellen Sie Seiten in erster Linie für Nutzer, nicht für Suchmaschinen. Versuchen Sie nicht, Ihre Nutzer zu täuschen. Stellen Sie zudem keinen Content für Suchmaschinen bereit, den Sie nicht für Ihre Besucher verwenden. Dies wird als "Cloaking" bezeichnet.

Eigentlich ist dies doch klar und versteht sich von selbst. Es gehört ohnehin zu den wohl frustrierenden Erkenntnissen eines Webbenutzers, wenn das von der Suchmaschine ermittelte Suchergebnis am Ziel vorbei führt.

Mir ist in den Jahren aufgefallen, dass es tatsächlich immer hilfreich ist, das an Informationen zu offenbaren, was man anderen - den Benutzern der Seite - auch wirklich mitteilen will. Wem nützt es, erotische "Fachbegriffe" versteckt in der Seite unterzubringen, nur weil über Suchmaschinen häufig danach gesucht wird? Ebenso wenig förderlich in der Sache ist es, Themenbegriffe x-Mal auf der Seite zu wiederholen. Nur weil ich gerne zum Thema AJAX.PRO schreibe, mich mit dem Thema AJAX leidenschaftlich gerne auseinandersetze, bringt es den Benutzer meiner Seite nicht weiter, platziere ich zu jedem Blogbeitrag diese Schlagworte. Der Benutzer der Seite freut sich vielmehr, gelangt er zielstrebig auch auf die Seite, wo ich mich mit dem Thema tatsächlich auseinander setze.

Ein weiterer Punkt, um bei Suchmaschinen erfolgreich zu sein ist es, die Regeln sauberen Webdesigns einzuhalten. Hierzu zählt ganz klar, die Vorgaben des W3C einzuhalten. Ich weiß, dass dies oftmals recht schwierig umzusetzen ist, doch bieten die Validatoren des W3C hier eine gute Unterstützung an: so wird eben nicht nur bei der CSS-Validierung das CSS als solches bemängelt, nein, man erhält auch gleich einen validen Vorschlag, wie die CSS-Definitionen aussehen könnten. Ähnlich verhält es sich bei der HTML-Validierung. Wer dem Ganzen noch die Krone gewissermaßen aufsetzen möchte, der sieht sich die Regeln für barrierefreies Webdesign an. Auch hier gibt es inzwischen einen guten Validator. Nun mag sich der eine oder andere sicher fragen, "Warum muss die Webseite barrierefreien Grundsätzen folgen?" - Ganz einfach, weil Suchmaschinen mit so genannten Crawlern arbeiten und diese sich mit weitgehend barrierefreien Webseiten am einfachsten tun.

Als ich das Weblog erstellt habe, war es für mich oberstes Gebot alle drei Grundsätze umzusetzen. Was man dabei feststellt: man macht sich viel mehr Gedanken darüber, was man wie an Informationen vermitteln will. Aber ebenso war für mich wichtig, Web 2.0 - Technologien - wozu unstreitig AJAX gehört - mit einzubringen.

So stand letztlich die Aufgabe, die Webseite so zu gestalten, dass sie mit und ohne Javascript gleichermaßen funktioniert. Sehr gute Dienste - mit Blick auf die Suchmaschinenoptimierung - hat hierbei das URL-Rewriting geleistet, denn es gehört zu einer Regel des suchmaschinenoptimierten Webdesigns, dass Parameterketten in der URL nicht von jedem Crawler untersucht werden. ASP.NET-MVC und auch ASP.NET 4.0 tragen dem Thema ebenso Rechnung.

Um im Rahmen der Optimierung dem Suchmaschinendienst entgegen zu kommen, bietet es sich an, eine Sitemap zu erstellen und zu pflegen. Auch hier gilt es die Regeln der Sitemaperstellung einzuhalten. Im Netz finden sich hierzu zahlreiche Anbieter die einen bei dieser Arbeit unterstützen können. Google selbst bietet ein Programm zur Generierung der Sitemap zum Download an. Daneben hat man bei Google die Möglichkeit einen RSS-Feed als Sitemap zu hinterlegen.

Zu guter Letzt kommt man aber nicht umhin, sich selbst im Netz bekannt zu machen - diesen Part kann einem die Suchmaschine nicht abnehmen. Verlinkungen von fremden Seiten auf die eigene ist mit Blick auf die Suchmaschinenoptimierung ein nicht unwesentliches Instrumentarium. Eine weitergehende sehr gute Übersicht zur Suchmaschinenoptimierung findet man bei Michael Sattler.

Im Rahmen dessen sollte man Verlinkungen auch auswerten, um so festzustellen, ob man sich gut platziert hat oder ob zum Beispiel Kooperationen den erhofften Erfolg tatsächlich sicherstellen. Für mich ist es immer wieder interessant zu sehen, nach welchen Begriffen Benutzer über die Suchmaschinen gesucht haben. Über den Referrer erhält man so zum Beispiel wertvolle Informationen zu einem Themengebiet und kann inhaltlich darauf reagieren.

Zusammenfassend bleibt also festzustellen: die Suchmaschinen geben dem Betreiber der Webseite einiges an die Hand - es ist Sache des Betreibers, sich an die Spielregeln zu halten und das Instrument gewinnbringend einzusetzen.

Website Konzeption

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 15 Nov 2009 20:21:30 GMT

Webseiten konzipieren - das ist leichter gesagt, als am Ende umgesetzt. Sicher geht es unter Umständen recht schnell. Wer kennt es nicht aus seiner jahrelangen Berufs- und/oder Projekterfahrung. Das Erwachen folgte auf dem Fuße, wenn ein Projekt gescheitert, ein wichtiger Kunde abgesprungen ist.

Jens Jacobsen hat inzwischen in der 5. Auflage sein Buch "Webseite Konzeption" herausgebracht. Der Untertitel des Buches ist auch Programm: Erfolgreiche Webseites planen, umsetzen und betreiben.

Im Wesentlichen unterteilt sich das Buch in 6 Bereiche:

Planung
Konzeption
Umsetzung
Betrieb
Tipps für spezielle Sites und Bereiche
Anhang (mit weiterführenden Informationen)

Wer sich das Buch bei seinen Projekten zu Hilfe nimmt, erfährt eine wertvolle Unterstützung bei der Umsetzung von Grob-, Fein- und Designkonzept und hierbei auch wertvolle Tipps, wie man auf Kunden eingehen kann bzw. sollte. Jens Jacobsen ist sich aber auch bewusst, dass es nicht wenige Probleme in der Konstellation Entwickler/Auftraggeber (in der Form Arbeitnehmer/Arbeitgeber) bei der Realisierung von Projekten gibt und geht somit auch auf diese näher ein.

Der Erfolg einer Webseite ist aber heute in entschiedenem Maße von einer gut funktionierenden Usability abhängig. Nicht selten steht und fällt ein Projekt damit. Als Projektverantwortlicher sollte man daher diesem Kapitel ein hohes Maß an Aufmerksamkeit schenken. Mit einer durchdachten guten Bedienbarkeit lösen sich oft auch andere Probleme - anders gesagt: Fehler in der Konzeption machen sich nicht selten im Usability wieder bemerkbar.

Für den später dann startenden Betrieb ist es natürlich unerlässlich, Maßnahmen der Qualitätssicherung nicht nur zu planen, sondern auch umzusetzen.

Für eine gute Webseite reicht es eben nicht, allein guten Willen zu zeigen, sondern sich ganz klar an den Gesetzmäßigkeiten der Webentwicklung zu halten und zu orientieren. Jens Jacobsen beschreibt hier in seinem Buch sehr gut und mit entsprechenden Beispielen untermauert, wie eine Webseite erfolgreich sein kann - und wie eben auch nicht.

Aus Entwicklersicht halte ich das Buch auch interessant, versteht man unter Umständen Projektverantwortliche besser (so sich diese an die in diesem Buch gegebenen Ratschläge orientieren). Gelegentlich soll es ja vorkommen, dass zu Kundengesprächen/-präsentationen Entwickler mitgehen. Dann ist man gut beraten, man hat die Teile Planung und Konzeption vorher einmal gelesen.

Unterm Strich bleibt für mich nur die Feststellung, dass das Buch "Website Konzeption" ein nahezu unverzichtbares Werk bei der Umsetzung von Webprojekten ist.

Der Autor betreibt unter http://www.benutzerfreun.de ein eigenes Webportal mit weiterführenden Informationen zu Fragen der Webseitenplanung und -konzeption.

Session einmal anders verwalten

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 14 Nov 2009 18:30:16 GMT

Gelegentlich ist es hilfreich, innerhalb seiner Webanwendung Informationen in eine Session abzuspeichern. Problematisch könnte hierbei sein, dass Sessions über einen Key verwaltet werden. Oft schon habe ich in Foren gelesen, dass Benutzer Stunden mit der Fehlersuche zugebracht haben, gleich dieser eigentlich offensichtlich war und in der fehlerhaften Schreibweise des Sessionkeys lagen.

Hierzu kann man über einen recht einfachen Weg für Klarheit sorgen:

Zum einen legt man sich einen Enum an, der letztlich alle Sessionkeys verwaltet. Das hat auch den entscheidenen Vorteil, dass man nicht ewig suchen muss, um herauszufinden, wie der Key richtig heißt oder ob es ihn überhaupt gibt. Gerade in Teams kann dies recht hilfreich sein. Ein anderer Vorteil ist natürlich das einhergehende Intellisense.

Im zweiten Step erzeuge ich mir eine statische Klasse zum eigentlichen Verwalten der Sessions. Die Klasse - ich nenne sie mal AppSession - hat zwei Methoden: Set und Get. Beide Methoden bekommen zum einen den Enum übergeben, der den Sessionkey repräsentiert und die Set-Methode bekommt zusätzlich den Value vom Type object mitübergeben.

Und das war dann schon die ganze Herrlichkeit.

In der späteren Konsumierung schauts doch dann recht übersichtlich und leicht verständlich aus.

Ja jetzt könnte man meinen, "ja so könnte man es machen, aber das geht doch auch noch viel cooler...". Klar geht das.

Man könnte jetzt Extension Methods benutzen und so das Page.Session-Objekt erweitern.

Dann würde das am Ende so ausschauen:

Eine statische Klasse für die erweiternden Methoden. Auch hier wieder die Methoden Set und Get. this ist hier vom Type System.Web.SessionState.HttpSessionState, damit die Erweiterung auch auf Page.Session greift. Statt des Methodennamens Set könnte man auch die Add-Methode überladen,

das würde auch gehen - in diesem Fall würde ich der Einheitlichkeit halber und der klaren Abgrenzung wegen bei Set als Bezeichner bleiben wollen. Man kann auch beides implementieren.

Die Implementierung schaut dann vollständig folgendermaßen aus:

Der Aufruf bleibt dann auch wieder übersichtlich und verständlich:

Wenn ich schon bei Erweiterungen bin, dann könnte ich natürlich auch den Enum erweitern um die Methoden Get und Set, so dass ich auf diesem Wege wieder den Sessionwert ermitteln bzw. setzen kann.

Die Implementierung orientiert sich dann anlog dem vorhergehenden Beispiel.

Am Ende rufe ich in jeder Implementierung die Get/Set-Methode der statischen Klasse AppSession auf.

Zum Debuggen sicher von Vorteil, da ich wieder eine zentrale Stelle habe, wo ich das Setzen oder Abrufen des Sessionwertes überwachen kann.

Der Vollständigkeit halber sollte man auch eine Remove-Methode nach der selben Vorgehensweise implementieren.

Den vollständigen Code findet ihr unter dotnet-snippets.de hier.

Nach Abschluss des Snippet-Wettbewerbes, also ab dem 13.12.09 gibt es die Beispielklasse nebst Enumbeispiel hier auch zum Download als Visual Studio 2008 Projekt.

Viel Spass beim Ausprobieren.

Optimierungsmöglichkeiten mit dem Scripmanager

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 08 Nov 2009 18:02:56 GMT

Wer im Rahmen seiner Anwendungsentwicklung geneigt ist, das AjaxToolkit einzusetzen, dem müssten dann und wann schon einmal Bedenken hinsichtlich der Performance gekommen sein. Mich hat es die Tage jedenfalls beschäfftigt, so dass ich mich im Netzt einmal auf die Suche nach einer passenden Lösung gemacht habe.

In diesem Blogbeitrag bin ich dann fündig geworden. Ein interessanter Aspekt ist sicher der Einsatz von HttpWatch. Es muss jedoch erwähnt werden, dass mit Fiddler ähnliche Informationen sich ermitteln lassen. Ebenso gut bekommt man auch Informationen über Firebug angezeigt. Seit dem Internet Explorer 8 kommt dieser mit einem recht ordentlichen Entwicklertool daher, das sich über F12 aufrufen lässt.

über den Tab "Profiler" kann man das Lade- und Aufrufverhalten seiner Javascripte genau analysieren.

Was die Einstellungen in der web.config-Datei angeht, ist man sicher gut beraten, wenn man hier noch einmal nachliest. Der für mich interessante Part war die Einstellungen zur Kompression und zum Cacheverhalten, wie in dem o.g. Blogbeitrag erwähnt.

Um die Einstellung EnablePartialRendering="true" kommt man indes beim Updatepanel wohl nicht herum. Auch kann ich die Aussage nicht teilen, LoadScriptBeforUI="false" sei eine optimale Einstellung. Ich habe z.B. den CalendarExtender innerhalb eines Updatepanels im Einsatz und da löst LoadScriptBeforUI="false" ein Fehlverhalten in der Form aus, dass der Extender erst gar nicht funktioniert. Erst wenn ich LoadScriptBeforUI="true" setze, funktioniert auch der Extender wieder. Ich denke, hier muss jeder den Einzelfall berücksichtigen.

Eine vorteilhafte Entscheidung ist es jedoch, statt des Standardscriptmanagers den des AjaxToolkit einzusetzen. Dieser verfügt über eine Möglichkeit, nur die Scripte des Toolkit zu laden, deren Controls auf der Seite auch verarbeitet werden.

Mit der Eigenschaft CombineScripts="true" und der Angabe eines HttpHandlers in der Eigenschaft CombineScriptsHandlerUrl kann man den ToolkitScriptmanger dazu bringen, die Scripte nicht einzeln zu laden sondern die Scriptressourcen in einer zusammenzufassen.

Im HttpHandler muss man lediglich folgenden Aufruf platzieren:

ToolkitScriptManager.OutputCombinedScriptFile(context)

Man ist gut beraten, sollte der Aufruf false zurückgeben, dies entsprechend auszuwerten.

Keine Angst vor Javascript

weblog@drescher-hackel.de (René Drescher-Hackel) — Tue, 13 Oct 2009 13:43:01 GMT

Mit der Entwicklung von Custom Webcontrols sind oft sehr klare Vorstellungen verbunden, was das Control im Einzelnen leisten soll. Oft sind auch Anforderungen allein in der Gestalt gegeben, dass auf allen Seiten, die das Control verwenden (sollen) ein einheitliches Markup verwendet wird. Knifflig wird es oft dann, wenn controlspezifisches Javascript mit eingebunden werden muss.

Nicht dass dies an sich ein Problem wäre - hierzu wird oft eine Javascriptdatei als Ressource im Control eingebettet und mit ausgeliefert.

Nein, die Problematik stellt sich oft in der Funktionalität des Javascripts. Hier steht z.B. jQuery als komplexe Javascript-Bibliothek im Raum - aber kann ich jQuery als Controlentwickler voraussetzen? Die nächste Frage, die sich stellt, ist die nach der richtigen Version? Oder liefer ich über das Control stillheimlich eine Version der jQuery-Bibliothek mit aus - aber was, wenn in der Seite eine andere Version schon eingebunden ist oder gar eine konkurrierende Bibliothek in der Seite schon Anwendung findet?

Diese Fragen haben mich erst kürzlich beschäftigt: ich bin zu dem Schluss gekommen, dass ein Control sich nie auf eine externe Bibliothek verlassen darf - eine derartige Abhängigkeit halte ich in der Controlentwicklung für schädlich. Ein weiteres Argument gegen eine solche Abhängigkeit ist die Tatsache, dass man nie weiß, wo das Custom Control letztendlich eingesetzt werden soll. Aus diesen Gründen plädiere ich dafür, sich stets auf das eigene Javascript zu verlassen.

1. Javascript != AJAX

Auf der diesjährigen BASTA-Konferenz war ich allerdings etwas erschrocken über die Aussage eines namhaften Buchautoren, der den Standpunkt vertrat, dass man es doch lieber lassen sollte mit den Webanwendungen, die Javascript konsumieren. Ich weigere mich in diesem Zusammenhang alles als AJAX-Anwendung zu bezeichnen, nur weil Javascript zum Einsatz kommt. Sein Argument, dass oft das Know-How und das Budget für solche Anwendungen in den Firmen nich ausreichend vorhanden sei, ist allenfalls etwas schwach, wenn man bedenkt, welche Alternative er vorgeschlagen hat - Silverlight. Kurioserweise brachte er aber ein Beispiel (die Zahlen auf Genauigkeit mal dahingestellt), dass im Vergleich zu Silverlight 10 Mal mehr Flash-Entwickler derzeit gesucht werden. Aber über diesen Standpunkt zum Thema Javascript könnte man sicher Bücher schreiben...

Fehlendes Know-How im Bereich Javascript kann man durch die entsprechende Lektüre sicher begegnen. Unschlagbarverzichtbar in diesem Zusammenhang ist für mich die Referenz bei selfHTML.

2. Vorüberlegungen

In diesem Beitrag möchte ich heute einmal aufzeigen, dass es gar nicht so schwer ist, mit dem Javascript.

Nehmen wir z.B. den immer wieder in den Foren nachgefragten Fall, dass ein DIV-Container weitere Elemente enthält und dieser sich durch einen Klick innerhalb eines bestimmten Bereiches zusammenklappen bzw. ausklappen soll. Dabei sollen aber weiche Übergänge möglich sein.

Also das Beispiel sollte dann so aussehen:

Das könnte gleichermaßen ein Custom Control sein, deren Erstellung ich aber heute nicht demonstrieren möchte. Bei einem Klick auf den hier grau markierten Kopfbereich sollte der darunter liegende Inhaltsbereich einrollen und weich ausgeblendet werden. Beim erneuten Klick sollte der Inhaltsbereich wieder ausrollen und entsprechend weich eingeblendet werden.

Um dieses Vorhaben zu realisieren, sollte man sich mit den Grundlagen des CSS befassen, damit man weiß, welcher Effekt sich mit welcher Styleeigenschaft umsetzen lässt. Unverzichtbare Quelle in diesem Zusammenhang ist neben selfHTML auch die Seite css4you.

Der Container an sich ist recht einfach, wie das folgende Markup zeigt:

Was man in diesem Zusammenhang wissen muss ist, dass die DIV-Elemente sogenannte Block-Elemente und daher immer untereinander angeordnet sind.

Damit das ganze etwas freundlicher aussieht, bekommen die einzelnen DIV-Elemente ein Style über das class-Attribute zugewiesen.

Für den äußeren umschließenden Container kommt folgendes Css zur Anwendung:

Hier ist wichtig, dass die Eigenschaft overflow auf hidden gesetzt ist und im Übrigen keine Höhe zugewiesen wird.

Für das innere obere DIV-Element kommt folgendes Css zur Anwendung:

Im Gegensatz zum umschließenden DIV-Element ist es hier wichtig, eine feste Höhe zu setzen. Die anderen Angaben dienen der allgemeinen Kosmetik.

Zum Schluss erhält das zweite innere DIV-Element noch einen individuellen Style zugewiesen:

Wichtig ist auch hier wieder die overflow-Eigenschaft, welche auf hidden gesetzt werden muss und dass keine feste Höhe zugewiesen wird.

Wenn denn alles richtig umgesetzt wurde, sollte folgendes Bild sich ergeben:

Es wird deutlich, dass der Inhaltscontainer in der Höhe von seinem eigentlichen Inhalt bestimmt wird - in diesem Fall ist noch kein Inhalt vorhanden, weshalb das zweite innere DIV-Element faktisch nicht zu sehen ist. Verantwortlich ist hierfür die Eigenschaft overfow, welche auf hidden steht. Lediglich das DIV-Element mit einer festen Höhe ist zu sehen.

3. Das Javascript

Kommen wir nun zu den Überlegungen zum Javascript: was wir wissen ist, dass die DIV-Elemente einen zugewiesenen Wert auf dem class-Attribute haben. Weiterhin ist die Struktur des gesamten Containers bekannt - ein DIV-Element mit zwei DIV-Elementen, wobei der erste das Event zum Verhalten des zweiten auslösen soll.

Orientiert an die Custom-Control-Entwicklung würde ich ein Javascriptobjekt vorziehen, wobei ich im window-onload-Eventhandler keine zusätzliche Instanziierung vornehmen müsste.

Die runden Klammern (rot markiert) bewirken, dass Container nicht nur die Definition des Objektes ist, sondern auch zugleich die Instanz dessen, so dass sofort damit gearbeitet werden kann.

Im Rahmen der Controlentwicklung gilt es jedoch den Click-Event zu registrieren. Hierzu kann man das Attribute onclick setzen und den Methodenaufruf direkt angeben. Wichtig ist hierbei, den Parameter event genau so mitzugeben, damit bei den Browsern, welche das window.event-Objekt nicht kennen/unterstützen, dieses zur Verfügung steht. Über das event-Objekt kann man letztlich immer erfahren, über welches DOM-Element das Event ausgelöst wurde.

Im Fall der vorgestellten Beispielanwendung, ziehe ich es vor, das Event über das übergeordnete DIV-Element zu binden.

3.1 Die Klick-Methode

Um das Event auch zu verarbeiten, bedarf es der Klick-Methode. Diese wird im öffentlichen Bereich der o.g. Javascriptdefinition definiert. Dies kann in zwei Formen geschehen: zum einen, indem auf eine interne Methode verwiesen wird (was ich vorziehe), zum anderen, indem die Methode direkt definiert wird.

Wird im public-Bereich auf eine interne (private) Methode verwiesen, so geschieht dies nur durch Angabe des Methodennamens - ohne die Signatur. Im späteren Aufruf muss dann aber die (public) Methode immer mit der vollständigen Methodensignatur (wie sie die private Methode vorgibt) aufgerufen werden.

Innerhalb der _click-Methode stellen wir als erstes fest, wer das Event eigentlich ausgelöst hat. Hierbei stoßen wir auf eine immer noch bestehende Browserproblematik: der Internet Explorer versteht als einziges das window.event-Objekt, während die übrigen Browser das Eventobjekt über die Argumentenliste der Methode transportieren. Man sollte jedoch wissen, dass das Eventobjekt nur ankommt, wenn im onclick-Attribut event so mit angegeben wurde. Wurde zum Beispiel onclick="Container.Click(evt)" angegeben, dann kann auch Firefox & Co. nichts damit anfangen. Innerhalb des aufgerufenen Eventhandlers gelangt man dann nicht mehr an das Eventobjekt. Der Internet Explorer hingegen kann innerhalb des Eventhandlers das Eventobjekt bestimmen. Daher erfolgt zu Gunsten der Browserkompatibilität als erstes in der Klick-Methode die Prüfung nach dem Eventobjekt.

Wie ich weiter oben schon erwähnte, kann man über das Eventobjekt feststellen, welches DOM-Element das Event ausgelöst hat. Auch hier stolpert man wieder über eine Browserbesonderheit: der Internet Explorer kennt die Eigenschaft srcElement, während die anderen Browser die target-Eigenschaft verstehen. Hier sollte man sich in der Prüfung der Browserkompatibilität auf die Abfrage der geforderten Eigenschaft verlassen und nicht auf das navigator-Objekt. Wenn das DOM-Element feststeht, versuchen wir als erstes das class-Attribute zu bestimmen. An dieser Stelle kann man ebenso gut das id-Attribut erfragen, doch möchte ich mich hier auf das class-Attribute beschränken. Beachten sollte man hier aber, dass das Attribute zwar class heißt, im Javascript aber über className ermittelt wird. Bisweilen ist im Netz auch zu lesen, dass die einzige richtige Syntax die ist, wo der Eigenschaftsname in eckigen Klammern objekt["eigenschaft"] angegeben wird. Ich bevorzuge hier jedoch die im .NET auch übliche Punktnotation (objekt.eigenschaft) - beides führt zum gleichen Ergebnis.

Von daher erweitert sich die Klick-Methode folgendermaßen:

Wenn das class-Attribute den Wert panel hat, dann soll die eigentliche Verarbeitung weiter gehen. Ist dies der Fall, gilt es das nachfolgende DOM-Element mit der css-Klasse content zu ermitteln. Und wie sollte es anders sein, treffen wir hier erneut auf eine Browserbesonderheit, wo sich die Geister scheiden, welcher Browser das richtige Ergebnis liefert. Während der Internet Explorer lediglich die echten DOM-Elemente findet, berücksichtigen die anderen Browser alle Elemente - auch die nicht sichtbaren, wie den Zeilenvorschub \n. Das richtige Element zu ermitteln ist allerdings nicht so schwer: jedes DOM-Element verfügt über eine Eigenschaft nodeType. Ist der Wert gleich 1, so haben wir ein HTML-Tag gefunden - und genau diese Elemente suchen wir ja. Um jetzt alle nachfolgende Elemente auf diese Eigenschaften zu überprüfen, bietet sich eine while-Schleife an. Diese wird so lange durchlaufen, wie das class-Attribute undefined ist (oder ein Element mit dem nodeType vom Wert 1 gefunden wurde). Das jeweils folgende Element erhält man immer über die Eigenschaft nextSibling.

Wie ich im Ergebnis später demonstrieren werde, kann man natürlich mehrere Elemente mit dieser Funktionalität endlos in einander verschachteln. Es empfiehlt sich daher an dieser Stelle das durchreichen (bubble) des Events abzubrechen. Alle aktuellen Browser verstehen die Eigenschaft event.cancelBubble, wobei doch empfohlen wird, die Methode stopPropagation aufzurufen, welche der Internet Explorer jedoch nicht kennt.

Der nun folgende Schritt ist etwas trickreich, erinnert aber auch leicht an die Vorgehensweise im jQuery. Im späteren Verlauf ist es wichtig, jedes Objekt eindeutig identifizieren zu können. Hierzu wollen wir aber nicht immer durch den DOM itterieren, zudem uns durch die gewollte DOM-Manipulation wichtige Informationen verloren gehen. Aus diesem Grund verfügt unser Javascriptobjekt Container eine private Eigenschaft elements vom Type Array. Dieses Array werden wir im Folgenden öfter durchsuchen, so dass ich zusätzlich eine prototype-Methode find implementieren werde. Um alle Elemente in diesem Array eindeutig identifizieren zu können, weisen wir dem nextElement die Eigenschaft guid zu. Eine Möglichkeit zum Erzeugen einer solchen GUID habe ich hier gefunden. Weiterhin speichern wir den derzeitigen Offsetwert der Elementhöhe über die Eigenschaft offsetHeight ab. Das Hinzufügen des über die o.g. while-Schleife gefundenen DOM-Elementes erfolgt nur ein einziges Mal - nämlich, wenn das Element noch nicht die Eigenschaft guid zugewiesen bekam.

Die Definition der Prototype-Methode für das Array-Objekt ist ebenfalls recht einfach: hier wird lediglich das Array über eine for-Schleife durchlaufen und wenn die id-Eigenschaft im Array-Element mit der über die find-Methode übergebenen id übereinstimmt, dann gibt die find-Methode genau das Array-Element an den Aufrufer zurück.

Nun sind wir schon fast am Ende der Klick-Methode angekommen. Bleibt nur noch das Eigentliche - nämlich die Implementierung des Ein- bzw. Ausrollen des Inhaltselements. Die Unterscheidung, was beim Klick-Event zu tun ist, kann zum Beispiel über die aktuelle Höhe des Elements erfolgen. Nachteilig ist hierbei, dass man nicht die Werte eines möglichen Rahmens, wenn diese in der css-Klasse gesetzt sind, zweifelsfrei ermitteln kann. Besser erscheint es mir hier, dem Element eine weitere Statuseigenschaft zuzuweisen. Für das eigentliche Ein- bzw. Ausrollen der Elemente habe ich zwei weitere private Methoden implementiert. Innerhalb dieser Methoden wird die Eigenschaft scrollOut gesetzt.

3.2. Die scrollOut-Methode

Für das Ein- bzw. Ausrollen des Inhaltsbereich kommt eigentlich nur eines in Frage - das dynamische Verändern der Höhe des Elementes. Die Frage, die sich hierbei stellt, ist die Form der Umsetzung.

Da wäre die for-Schleife, die while-Schleife oder der rekursive Aufruf einer Methode. Alle Lösungsansätze haben aber ein Manko gemeinsam - sie können nicht warten. Mir ist kein Befehl im Javascript bekannt, der analog einer PAUSE 20 Anweisung im guten alten BASIC enspricht. Wenn man aber in bestimmten Abständen etwas immer und immer wieder aufrufen bzw. abarbeiten lassen möchte, so kommt dies einem Intervallverhalten nahe. Und genau dafür gibt es im Javascript eine entsprechende Methode im window-Objekt: window.setInterval. (Anmerk.: man könnte aber auch eine Methode rekursiv aufrufen und innerhalb der Methode mit der Anweisung setTimeout arbeiten.). Ein weiterer Vorteil an der Methode setInterval ist, dass man hier einen Zeitwert in Millisekunden mit angeben kann, in welchen Abständen das Intervall aufgerufen werden soll.

Wichtig bei der Verwendung der Methode setInterval ist die Zuweisung der von setInterval zurückgegebenen IntervalID an eine Variable. Ohne diese IntervalID kann sonst der Vorgang nicht abgebrochen werden. Um diesen Intervallabbruch zu erzeugen, benötigen wir eine Abbruchbedingung.

Beim Ausrollen des Inhaltsbereiches ist die Abbruchbedingung eigentlich klar: das Element hat die zulässige maximale Höhe erreicht. Und an dieser Stelle kommen wir zurück auf die Klick-Methode: hier hatte ich die Offsethöhe des Elements in einem separaten Objekt erstmals zwischen gespeichert.

Nach all diesen Vorüberlegungen kann es nun an den Code gehen:

Die Methode _scrollOut bekommt als Parameter das entsprechende DOM-Element mit übergeben. Im ersten Schritt merken wir uns den Status über eine zusätzliche Eigenschaft - scrollOut - indem wir sie auf true setzen. Dies ist vor allem für die Momente interessant, wo der Benutzer während des Ausrollens das Einrollen des Elementes veranlasst (dazu weiter unten mehr). Dann holen wir über die find-Methode das Array-Element, welches der guid-Eigenschaft des übergebenen DOM-Elementes entspricht. Haben wir dieses Element innerhalb des Array elements gefunden, kann die weitere Verarbeitung erfolgen. Der erste Schritt ist hier nun zu prüfen, ob für dieses Element (item) noch aktuell ein anderes Intervall läuft - dieses müsste nämlich dann als erstes beendet werden. Da sich die Aufrufe für die Methode clearInterval an mehreren Stellen wiederholen, spendieren wir hierfür eine kleine interne Methode, welche clearInterval aufruft und die bestehende IntervalID löscht. Um im Fall des Umschaltens während eines laufenden Intervalls immer mit dem jeweils richtigen Wert der Höhe weiter zu arbeiten, speichern wir den aktuellen Wert in einer Eigenschaft auf dem item-Objekt. Auch verfahren wir mit der IntervalID gleichermaßen, indem wir sie über das item-Objekt speichern - dies versetzt uns in die Lage, bei jedem Methodenaufruf festzustellen, ob für dieses Objekt ein (anderes) Intervall läuft.
Innerhalb der Intervallmethode prüfen wir als erstes, ob die Abbruchbedingung für das Intervall eingetreten, die Endhöhe des Elements erreicht ist. Ist die der Fall, beenden wir das Intervall und setzen das Element auf den ursprünglichen Offsetwert der Höhe. Da nun die ganze Zeit mit Pixelwerten in der dynamischen Zuweisung der Höhe gearbeitet wurde, die Höhe aber aufgrund möglicher Verschachtelungen mit anderen Elementen dynamisch bleiben muss (vergleiche hierzu das Ergebnis am Ende), setzen wir zu guter Letzt die Höhe auf 100%.
Ist die Abbruchbedingung nicht erreicht, setzen wir die aktuelle Höhe für diesen Aufruf und zählen den Wert für die Höhe weiter hoch.
Dieser Wert, der hier hinzuaddiert wird, ist neben der Intervallpause maßgeblich dafür verantwortlich, wie schnell das Element ein- bzw. ausrollt. Merke: je kleiner dieser Wert ausfällt, desto langsamer der Prozess. Bei der Intervallpause ist das Verhältnis genau umgekehrt: je größer der Wert, desto langsamer (und abgehackter) ist der Prozess. Tip: der Wert für die Intervallpause sollte den Wert 50 nicht überschreiten.

Im Ergebnis erhalten wir nun folgende Methode:

3.3. Die scrollIn-Methode

Die Methode _scrollIn ist analog der Methode _scrollOut aufgebaut, so dass ich im folgenden nur noch auf die Unterschiede zwischen den Methoden eingehen möchte.

Im ersten Schritt setzen wir die scrollOut-Eigenschaft auf false. Den Wert für die Starthöhe holen wir uns aus der Eigenschaft currentHeight des item-Objektes. Statt einen Wert auf die Höhe hinzuzurechnen, ziehe ich den (gleichen) Wert hier von der jeweils aktuellen Höhe ab.

Am Ende sieht die _scrollIn-Methode folgendermaßen aus:

Wenn man bis jetzt alles richtig gemacht hat, erhält man folgende Anwendung:

Klick hier zum testen...

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu.

In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus.

Klickt man auf den grauen Bereich, rollt der darunter liegende Bereich ein bzw. aus.

Aber die oben genannte Aufgabenstellung bestand ja darin ein weiches ein- bzw. ausrollen zu realisieren. Hier kommt also noch hinzu, das Ein- oder Ausblenden in Form eines Fading zu implementieren.

3.4. Fading

Um ein weiches Aus- und Einblenden umzusetzen, kommt nur die Style-Eigenschaft opacity in Betracht.

An dieser Stelle stoßen wir wieder auf eine Browserbesonderheit. Der Internet Explorer kann die opacity-Eigenschaft nicht direkt umsetzen, wie die anderen Browser, das funktioniert hier nur über die filter-Eigenschaft.

Beim Setzen der Eigenschaft muss man weiter beachten, dass der Internet Explorer einen Wertebereich von 0 - 100 kennt, die anderen Browser über die Style-Eigenschaft opacity nur einen Wertebereich von 0 bis 1 verarbeiten können.

In der weiteren Planung können wir uns ganz auf die obere Vorgehensweise zum Setzen der Höhe verlassen - eigentlich hat sich nur die Eigenschaft (und etwas an der Berechnung) geändert.

3.4.1 FadeIn

Die Methode bekommt wieder das DOM-Element übergeben. Was an dieser Stelle nicht benötigt wird, ist eine Statuseigenschaft, die Auskunft darüber gibt, ob gerade ein- oder ausgeblendet wird - dazu später mehr. Somit wird wieder aus dem elements-Array das aktuelle zum DOM-Element korrespondierende item abgerufen. Ist das item-Objekt gefunden, wird auch hier wieder geprüft, ob noch ein Prozess des Ein-/Ausblenden läuft und ggf. abgebrochen. Der aktuelle opacity-Wert wird aus dem item-Objekt ermittelt und der internen Zählvariablen zugewiesen. Die Umrechnung und Zuweisung des opacity-Wertes erfolgt dann in einer internen Hilfsmethode.

Wenn die Eigenschaft filter unterstützt wird, dann wird der alpha-Filter gesetzt. Bei der Zuweisung des opacity-Wertes innerhalb des alpha-Filters wird der übergebene Wert einfach mit 100 multipliziert. In allen anderen Fällen wird die opacity-Style-Eigenschaft direkt gesetzt.

Zu guter Letzt wird wieder geprüft, ob die Abbruchbedingung für das Intervall eingetreten ist - der Wert für opacity ist größer gleich 1. In diesem Fall wird clearInterval wieder aufgerufen, andernfalls wird der Wert aufaddiert. Hier gilt das gleiche, wie beim Ein-/Ausrollen: je kleiner der Wert, der hinzuaddiert wird, desto langsamer ist der Prozess des Einblenden.

Am Ende erhält man dann folgende Methode:

3.4.2 FadeOut

Die _fadeOut-Methode gestaltet sich analog, nur dass eben kein Wert hinzuaddiert sondern abgezogen wird.

Zum Schluss bleibt die Frage, wie das Ganze im Prozess des Ein-/Ausrollens integriert wird. Ganz einfach: die Methode _scrollIn bzw. _scrollOut wird jeweils um die Methode _fadeOut bzw _fadeIn erweitert, und zwar genau an der Stelle, nachdem geprüft wurde, ob die item.scroll-Eigenschaft noch gesetzt ist.

bzw.

Da wir innerhalb der _scrollIn bzw. _scrollOut Methoden schon mit einer Statuseigenschaft arbeiten, benötigen wir für den Prozess des Fading keine weitere Statuseigenschaft. Dies ist nur erforderlich, wenn das Fading eigenständig aufgerufen werden sollte. Dann kann man hier analog zur Statuseigenschaft scrollOut verfahren.

Hat man alles richtig gemacht, erhält man folgende fertige Lösung:

[1] Klicke hier, um zu testen...

[2] Klicke hier, um zu testen...

Im Ergebnis sollte die Erkenntnis gekommen sein, dass Javascript kein Teufelszeug ist, vor dem man Angst haben muss. Der Einsatz von Javascript in seinen Webanwendungen setzt nur folgendes voraus: Kenntnis vom Aufbau des DOM, Kenntnisse von Css-Eigenschaften und was diese bewirken und letztlich das Wissen, dass man auch mal eine gängige Suchmaschine benutzen sollte, wenn man doch nicht alles sofort parat hat. Auch wenn ich mich erneut wiederhole, doch kann man es nicht oft genug sagen: eine aus meiner Sicht nahezu unverzichtbare Quelle als Nachschlagewerk stellt selfHTML dar. Dessen sollte man sich immer bewusst sein. Und da bedarf es keiner exorbitanten Budgets oder Herrscharen von Javascriptentwicklern. Man muss einfach bereit sein, sich mit diesem Sprachelement auch ernsthaft auseinander zu setzen. Dies gilt aber auch dann, wenn man sich für ein Javascript-Framework wie z.B. jQuery entscheidet.

Bug oder Feature - DataBinding der CheckBoxList

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 13 Sep 2009 14:14:59 GMT

Im Rahmen meiner beruflichen Tätigkeit war es wieder mal so weit, sich mit der Entwicklung von Custom Controls näher auseinander zu setzen. Custom Controls bieten dabei aus meiner Sicht einen unschätzbaren Vorteil: über das Control kann man allen Benutzern des selben so klare Vorgaben machen, dass das Endergebnis im Webprojekt auch wirklich immer gleich aussieht. So kann man "frecherweise" bestimmte Eigenschaften so setzen, dass sie bewußt überschrieben werden. Aber das soll heute nicht das eigentliche Thema sein.

Bei der Planung des Custom Control - und wer immer sich damit beschäftigen will - ist es stets hilfreich, sich doch einmal mit den Grundlagen der Controlentwicklung zu beschäftigen. Einen etwas älteren - aber immer noch aktuellen - Ansatz bietet hierbei der Webcast von Daniel Walzenbach. Um es an dieser Stelle gleich vorweg zu nehmen, es bleibt vieles in der Webcastserie an der Oberfläche und beschränkt sich i.d.R. auf diverse Samples, welche man auch in der MSDN-Sammlung wiederfindet. Dennoch ist diese Webcastserie meines Erachtens unverzichtbar beim Einstieg in die Controlentwicklung.

Wer schon mal die Controls von Infragistics oder vom AjaxToolkit eingesetzt hat, dem dürften diverse verschachtelte Controls aufgefallen sein. Daniel Walzenbach erklärt in seiner Webcastserie sehr ausführlich, wie man dieses Verhalten umsetzen kann. Am Ende werden zu den Properties bestimmte Attribute gesetzt.

Vor diesem Hintergrund kam mir der Gedanke: warum soll ich alles von Hand implementieren, wenn ich doch gleich ein .NET-Webcontrol als Nested-Control verwenden kann. Was mit einer Property vom Type Style geht, sollte auch mit einer TextBox oder einer CheckBoxList funktionieren.

Und in der Tat - es funktioniert. Somit konnte ich mir sehr viel Arbeit ersparen (welche Daniel Walzenbach im Webcast noch für zwingend erforderlich hielt).

Nun waren noch die Punkte des Postback-Verhalten und der Datenbindung zu klären. Man möchte nun meinen, dass die Standardwebcontrols alles implementiert haben? Ja und nein - den IPostBackDataHandler muss man trotzdem im Custom Control implementieren. Was man aber nicht mehr benötigt, ist die detailierte Vorgehensweise, wie sie vom Daniel im Webcast beschrieben wurde - zumindest nicht, soweit es die Standardwebcontrols betrifft. Hier genügt es in der LoadPostData-Methode den Wert true zurück zu geben.

Für alle anderen Fälle bleibt es dabei, dass die Werte verglichen werden müssen.(siehe unten)

Ein weiterer Punkt ist die Datenbindung. Hier bin ich fast verzweifelt. Am Ende stellte sich die Frage, wieso gibt es hierfür keine vernünftige Implementierung im .NET-Framework? Doch was ist geschehen: Nehme ich ein List-Steuerelement, w.z.B. eine CheckBoxList und binde sie an eine Datenquelle, dann passiert das i.d.R. folgendermaßen:

Man möchte meinen, dass der Checked-Status der einzelnen Elemente aus der Datenquelle übernommen wird. Aber weit gefehlt. Erstaunlicherweise hatte sich Peter Bucher mit diesem Thema schon einmal auseinander gesetzt und es scheint mir die derzeit plausibelste Vorgehensweise für dieses Problem.

Im Rahmen der Custom Control Entwicklung wollte ich jetzt nicht noch ein Custom Control ins Spiel bringen, zu mal ich ja direkten Einfluss auf den Renderprozess des Controls (der CheckBoxList) habe. Folglich habe ich mich für einen anderen Weg entschieden - der z.T. durch das Projekt mit bedingt war.

Das Rendern der CheckBoxList habe ich selbst übernommen und so direkten Einfluss auf die Eigenschaften der einzelnen CheckBox genommen. Orientiert habe ich mich am Renderprozess des CheckBoxList-Control selbst.

Um den Checked-Status der CheckBoxen richtig setzen zu können, habe ich dem Custom Control eine Property zugewiesen, welche die einzelnen Werte separiert verwaltet, zuzüglich einer Eigenschaft für den Delimiter.

Zu guter Letzt musste ich mich nur noch um den PostBack kümmern. Hierzu habe ich dann in der LoadPostData-Methode folgende Codezeilen eingefügt:

Analog ist dann auch die Vorgehensweise beim DropDownList-Control, wenn denn die Mehrfachauswahl zugelassen ist.

Es bleibt aber zu hoffen, dass dieses Manko - und das ist es in der Tat - in eine der nächsten Versionen allgemeingültig behoben ist.

Datengebundene Webanwendungen mit AJAX.PRO

weblog@drescher-hackel.de (René Drescher-Hackel) — Fri, 24 Jul 2009 10:04:07 GMT

Immer wieder lese ich im Netz, dass Anwender sich schwer damit tun, AJAX.PRO in ihren Projekten einzusetzen. Dabei ist der Einstieg aus meiner Sicht bald noch einfacher, als wenn man das Ajax-Toolkit einsetzen möchte. Was braucht es dazu? Zum einem reicht es aus, wenn man der englischen Sprache mächtig ist, denn Michael Schwarz hat es zielgruppenorientiert eigentlich sehr gut auf seinen Webseiten dokumentiert.

Wer dem Englischen nicht so zugewandt ist, dem ist es ja freigestellt den nachfolgenden Ausführungen zu folgen.

1. Voraussetzungen

Als erstes sollte man sich die Ajax.Pro-Bibliothek aus dem Netz beschaffen. Diese ist mit und ohne Quellcode unter dem Portal codeplex hinterlegt und abrufbar. Hierbei sollte man wissen, dass die Weiterentwicklung durch Michael Schwarz abgeschlossen ist. Es steht jedoch jedem frei, die Bibliothek unter der Maßgabe der Lizenzvereinbarung weiter zu entwickeln. Nach dem Entpacken der Zip-Datei erhält man einen Ordner mit 4 verschiedenen Assemblies und einer Beispiel-web.config-Datei.

Der nächste Schritt ist dann die Einbindung in das eigene Webprojekt - dazu sollte eine Referenz auf eine Ajax.Pro-Bibliothek gesetzt werden.

Im Webprojekt wählt man dazu über das Contextmenü auf dem Knoten Reference den Eintrag Add Reference, so dass sich dann das Dialogfenster öffnet.

Über den Register Browse navigiert man zu dem Verzeichnis, in dem man zuvor die Zip-Datei entpackt hat. Für eine .NET 1.x - Anwendung wählt man die AjaxPro.dll aus für alle anderen (also .NET 2.0 aufwärts) die AjaxPro.2.dll.

Hat man alles richtig gemacht, erscheint die Referenz unterhalb des Referenz-Knotens.

Weiter muss die web.config-Datei erweitert werden, indem ein Http-Handler im system.web-Knoten hinzugefügt werden muss.

Dabei gilt es zu beachten, dass AjaxPro.2 nur dann anzugeben ist, wenn auch die entsprechende Assembly dazu eingebunden ist. Orientieren kann man sich hier sehr schön am Eintrag unterhalb des Knoten Reference.

Der nächste Schritt gilt der eigentlichen Client-Server-Kommunikation. In meiner praktischen Anwendung von Ajax.Pro hat es sich über die Jahre bewährt, hierfür dem Projekt eine separate Klasse hinzuzufügen. Dies hat vor allem den Vorteil, dass man alle Ajax-Server-Methoden zentral an einem Ort hat. Die Ajax-Methoden müssen dabei mit einem gesonderten Attribute versehen werden, so dass später klar ist, welche Methoden am Client verfügbar sein sollen. Der Klasse selbst kann man ebenfalls ein Attribut zuordnen, um so z.B. komplexere Namespaces kürzer zu fassen oder die Serverarchitektur am Client nicht völlig offen zu legen. Hilfreich ist weiterhin, über die using-Anweisung den AjaxPro-Namespace der Klasse hinzuzufügen.

Der letzte Schritt ist dann die Registrierung der AjaxPro-Klasse für die eigentliche Verwendung am Client. Mit dieser Registrierung werden Javascriptobjekte erzeugt und in die Seite mit eigebunden, die es dem Anwender erst ermöglichen mit dem Server via Ajax.Pro(Javascript) zu kommunizieren. Für die Registrierung ist im Page_Load-Eventhandler der Seite der folgende Eintrag erforderlich:

Der zweite Parameter in der Methode RegisterTypeForAjax ist optional, wobei es sich in der Praxis bewährt hat, ihn mit anzugeben. Bei der Verwendung von Masterpages erfolgt die Registrierung i.d.R. im Page_Load-Eventhandler der Masterpage.

Auf der Serverseite haben wir nun alle Voraussetzungen geschaffen, um auf der Anwendungsseite eine AJAX-Anwendung umsetzen zu können.

2. Anwendung

Wenden wir uns nun der clientseitigen Implementierung zu. Einer der vielen Vorteile von Ajax.Pro besteht darin, dass die eigentliche Lernkurve sehr gering ausfällt - das, was man in den serverseitigen Aufbau investiert hat, kann man eins zu eins auf der Clientseite wiederfinden. Die folgende Grafik soll dies verdeutlichen.

Auf der Serverseite wurde in dem Beispiel der Namespace auf Web.Server festgelegt (lila Markierung). Im Watchfenster kann man sehen, dass genau diese Objektstruktur am Client vorhanden ist. Die Ajaxmethode (grüne Markierung) ist ebenfalls unter gleichen Namen am Client wiederzufinden. Ein Blick auf den Rückgabetype der Ajaxmethode (orange Markierung) offenbart einen weiteren Vorteil von Ajax.Pro: man kann nahezu fast jedes .NET Objekt als Rückgabetype angeben. Ajax.Pro seriealisert diesen zum Client (und auch vom Client zum Server, wie weiter unten zu sehen), ohne dass man eine Zeile extra Code hierzu zu schreiben hat. Der Aufruf der Servermethode vom Client aus liefert immer ein Resultobjekt zurück. Die zwei wichtigsten Eigenschaften des Resultobjektes sind das error-Objekt und das value-Objekt. War der Aufruf am Server erfolgreich, also fehlerfrei, so ist das error-Objekt immer null. Das value-Objekt beinhaltet immer den Rückgabetyp der Servermethode. In der Grafik oben kann man sehr schön erkennen (orange Markierung), dass im Wege der Serialisierung die Eigenschaften des Objektes auch auf der Clientseite zur Verfügung stehen. Mit diesem Wissen ist man in der Lage, Ajax-Anwendungen zu erstellen, ohne dass es z.B. eines Updatepanels bedarf. Mit Ajax.Pro konzentriert sich der Entwickler auf das wesentliche einer Ajax-Anwendung, dem Datentransfer.

Ich habe zum besseren Verständnis ein kleines Beispielprojekt erstellt, in dem es darum geht, Daten aus einer Datenquelle auszulesen, am Client anzuzeigen, zu bearbeiten, Daten zu löschen und neue Daten hinzuzufügen. Im Wesentlichen sind dies die Standardaufgaben bei datengebundenen Webanwendungen - man möchte Daten lesen, bearbeiten, hinzufügen oder löschen. Wie einfach das ganze mit Ajax.Pro geht, möchte ich an Hand dieser Beispielsanwendung demonstrieren.

2.1 Die Datenquelle

Als Datenquelle habe ich eine einfache XML-Datei gewählt, wobei sich das Beispiel auch auf jede andere Datenquelle übertragen lässt. Der Aufbau der XML-Datei ist recht einfach gehalten: es gibt n-Benutzer Elemente, wobei jedes Benutzer-Element ein Attribute id besitzt und zwei weitere Childnodes, für Vorname und Nachname. über das mit dem .NET SDK bereitgestellte Tool xsd.exe habe ich noch eine passende .NET Klasse erzeugt. Wie sich die Klasse verwenden lässt, weiter unten im Text dann.

2.2 Das Javascript

Immer wieder lese ich in den Foren, dass Webentwickler zwar eine Ajax-Anwendung umsetzen möchten, Javascript aber auf der anderen Seite möglichst vermieden wird. Doch das JA im Wort AJAX steht für Javascript. Wie sieht die Implementierung für Ajax.Pro aus. Kommen wir noch mal zurück zu der vorangegangenen Grafik: der Namespace in der Ajax.Pro-Klasse findet sich auch auf der Clientseite wieder, ebenso wie die Methodennamen der Ajax-Methoden. Der Abruf einer Liste von Benutzern aus der Xml-Datenquelle sollte dann folgendermaßen aussehen:

Über den onload-Eventhandler rufe ich die Methode GetBenutzerListe auf. Innerhalb dieser Methode findet die eigentliche Kommunikation mit dem Server statt, indem die Servermethode über Web.Server.GetBenutzerListe aufgerufen wird. Der Aufruf an sich gibt ein Resultobjekt zurück. Würde man so verfahren, dann hätten wir einen synchronen Serveraufruf. Damit der Aufruf letztendlich asynchron erfolgt, wird der Servermethode einfach der Callbackhandler mitgegeben. Der Callbackhandler ist dabei kein Methodenparameter im eigentlichen Sinne, sondern eine weitere Javascriptmethode. Diese wird immer dann aufgerufen, sobald die Kommunikation mit dem Server abgeschlossen ist. Das Resultobjekt ist dabei ein Methodenparameter des Callbackhandlers.

Das Resultobjekt hat wiederum weitere Eigenschaften, wobei die zunächst zwei wichtigsten das error-Objekt und das value-Objekt sind. Das error-Objekt sollte immer vorab auf null geprüft werden, bevor mit der eigentlichen Verarbeitung des Rückgabewertes begonnen wird. Wird ein konkretes Objekt in der Rückgabe erwartet, so hat es sich in der bisherigen Praxis bewährt, zusätzlich das value-Objekt ebenfalls auf null zu prüfen. Ist das error-Objekt nicht null, so sollte man sich Szenarien überlegen, wie man mit der weiteren Fehlerbehandlung am Client verfährt. Die Message-Eigenschaft des error-Objektes beinhaltet eine deatilierte Fehlermeldung, die der Exceptionmessage entspricht. Es ist selten zu empfehlen, die Fehlermeldung am Client direkt auszugeben - das sollte man sich gründlich überlegen.

In dem Beispiel wird eine Dropdownliste mit den vorhandenen Benutzern erstellt. Der Aufbau der Dropdownliste orientiert sich an allgemeinen Javascriptgrundlagen, wobei SELFHTML stets eine gute Quelle zum Nachschlagen bietet.

Nun, ich muss zugeben, bis hierher gab es noch keinen wirklichen Grund, für den Einsatz von Ajax.Pro, denn eine Dropdownliste kann man auch serverseitig an eine Datenquelle binden. Aber ich habe ja Eingangs geschrieben, dass ich zeigen möchte, wie man mit Ajax.Pro Daten anzeigen und bearbeiten kann.

Um nun die Benutzerdaten der Dropdownliste zu bearbeiten, versehen wir diese mit einem onchange-Eventhandler, der dafür Sorge tragen wird, dass das Miniformular

mit den entsprechenden Daten versehen wird. Auch hier könnte man den Einwand erheben, dass ja die Daten schon in der Dropdownliste vorhanden sind, doch soll hier mit diesem Beispiel die einfache Kommunikation mit dem Server demonstriert werden. Der Eventhandler der Dropdownliste führt dabei folgenden Code aus:

Der onchange-Eventhandler ist hier die Javascriptmethode GetBenutzer. über Web.Server.GetBenutzer (grüne Markierung) wird der Server aufgerufen. Als Parameter wird die ID des Benutzers erwartet (rote Markierung). Die Ajax-Methode GetBenutzer gibt dabei ein Objekt vom Type Benutzer an den Client zurück (pinkfarbene Markierung). Im Javascript wird wieder ein Callbackhandler (blaue Markierung) mit angegeben, der wieder aufgerufen wird, wenn der Server mit der Verarbeitung der Anfrage fertig ist. Auf der Serverseite wird die XML-Datenquelle geladen und genau das Element gesucht, das im id-Attribute-Wert dem übergebenen String entspricht. Hier habe ich die Benutzerklasse so gestaltet, dass wenn kein Benutzer in der Datenquelle gefunden wurde (weil z.B. ein anderer Anwender diesen zwischenzeitlich gelöscht hat), immer ein leeres Benutzerobjekt mit einer neuen Guid in der ID-Eigenschaft zurückgegeben wird. Diesen Umstand werden wir später noch gut zu verwenden wissen. Schaut man sich das Ganze mal in Ruhe an, so stellt man fest, dass immer der gleiche Ablauf erfolgt: der Client ruft den Server, der Server verarbeitet Daten und gibt eine bestimmte Information wieder an den Client zurück. Die gesamte Logik liegt dabei ausschließlich am Server. Was aber auch auffällt ist wieder das, was Ajax.Pro ausmacht: es wird kein Page-Lifecycle durchlaufen, sondern es werden nur die reinen Daten zwischen Client und Server ausgetauscht - ganz ohne Updatepanel.

Nachdem ich nun die Daten in das Formular geladen habe,

möchte ich sie auch verändern und am Server wieder abspeichern können. Dazu erweitere ich das Formular um einen Button, der die Speicherfunktion über den onclick-Eventhandler aufruft. Die o.g. Javascriptmethode WriteBenutzer habe ich inzwischen erweitert, um mir den aktuell ausgewählten Benutzer am Client zwischenzuspeichern, denn wie ich Eingangs schön erwähnte, kann ich mit Ajax.Pro .NET Objekte zwischen dem Server und dem Client in beiden Richtungen austauschen - diesen Umstand möchte ich beim Speichern des Benutzerobjektes gerne nutzen. Schauen wir uns den Code einmal an:

Inherhalb der Javascriptmethode SaveBenutzer übertrage ich die Formulardaten in das aktuelle Benutzerobjekt currentBenutzer. Im Anschluss wird die Ajaxmethode SaveBenutzer (rote Markierung) aufgerufen und das aktuelle (veränderte) Benutzerobjekt als Parameter (orange Markierung) mit übergeben. Ohne das es jetzt einer zusätzlichen Zeile Code bedarf, ist sofort eine Instanz der Klasse Benutzer mit den entsprechenden Daten am Server verfügbar. Somit braucht man nur noch die Save-Methode der Klasse Benutzer (blaue Markierung) aufrufen. An dieser Stelle könnte man jetzt die Werte noch validieren, wobei auch hier Ajax.Pro mir einen kleinen Teil der Validierung abnimmt: immer wenn die Wertzuweisungen vom Typ sich nicht übertragen lassen, wird eine Exception ausgelöst, was zu Folge hat, dass das error-Objekt im Resultobjekt nicht mehr null ist - die Anwendung auf der Clientseite bleibt nahezu unbetroffen; es bleibt Aufgabe des Entwicklers, das error-Objekt sinnvoll auszuwerten. Hat die Save-Methode der Benutzerklasse true zurückgegeben, so gibt die Ajaxmethode die aktuelle (veränderte) Liste an den Client zurück. Als Callbackhandler (lila Markierung) wurde WriteBenutzerListe angeben, mit der Folge, dass die Dropdownliste am Client sofort aktualisiert wird. Und wieder hat Ajax.Pro sich auf das Wesentliche beschränkt - dem reinen Datentransfer. Interessant ist in diesem Zusammenhang die Betrachtung, wenn statt der Liste null am Client ankommt - in diesem Fall wird die Dropdownliste nicht aktualisiert und am Client wird die Meldung ausgegeben, dass das Speichern fehlgeschlagen ist. Doch hierzu muss der Callbackhandler WriteBenutzerListe angepasst werden. Bevor ich dies tue, möchte ich das Resultobjekt noch einmal näher betrachten.

Neben dem error-Objekt und dem value-Objekt beinhaltet das Resultobjekt noch ein weiteres wichtiges Objekt - das request-Objekt mit den Eigenschaften args und method. Die method-Eigenschaft gibt Auskunft darüber, welche Servermethode aufgerufen wurde. Das args-Objekt beinhaltet alle an die Servermethode übergebene Parameter (Arguments). Mit diesem Hintergrundwissen kann der Callbackhandler WriteBenutzerListe nun angepasst werden.

Wenn also das value-Objekt null ist, obwohl ein Objekt erwartet wurde - nämlich die Benutzerliste - dann wird über die method-Eigenschaft des request-Objektes unterschieden, welche Meldung am Client auszugeben ist. Die Dropdownliste bleibt in diesem Fall unverändert, da ja die gewünschte Aktion am Server fehlgeschlagen ist.

Nicht viel anders verfährt man, will man einen Benutzer aus der Datenquelle löschen. Hierzu definiere ich wieder einen separaten Button, der mit einem onclick-Eventhandler versehen wird, welcher eine Javascriptmethode aufruft, die ihrerseits wieder eine Servermethode aufruft und dabei das zu löschende Benutzerobjekt an den Server übergibt und im Callbackeventhandler die Liste neu füllt. Auch hier wieder der Code im Detail:

Die Javascriptmethode DeleteBenutzer stellt den onClick-Eventhandler des Löschen-Button dar. Als erstes wird das Infopanel gelöscht, da der Benutzer eine neue Aktion angestoßen hat. Dann wird die Servermethode DeleteBenutzer (orange Markierung) der Ajaxklasse aufgerufen, wobei das aktuelle Benutzerobjekt wieder an den Server mit übergeben wird. Vom Prinzip hätte an dieser Stelle auch ein String genügt, die ID des Benutzerobjektes. Als Callbackhandler (blaue Markierung) wurde wieder die Methode WriteBenutzerListe angegeben, da ja nach erfolgreicher Löschung des Benutzers die Liste wieder aktualisiert werden muss, weshalb auch der Rückgabewert des DeleteBenutzer-Methode wieder die Liste(Array) der Benutzer ist (grüne Markierung). Da ich das Benutzerobjekt wieder sofort am Server verfügbar habe, kann hier die Delete-Methode der Benutzerklasse aufgerufen werden (rote Markierung). Anders als beim Speichern, muss mit dem Rückgabewert null hier verfahren werden. Wenn Benutzer.Liste() null zurückgibt, dann ist die Liste leer. Daher habe ich mich hier der Vorzüge des error-Objekts bedient und einfach eine Exception ausgelöst (lila Markierung), wenn das Löschen am Server fehlschlägt. Auf der Clientseite übertrage ich dann einfach die Exceptionmessage in das Infopanel. Für den Fall, dass das value-Objekt null ist, muss sichergestellt sein, dass die Dropdownliste keine Einträge enthält. Dies erreicht man, indem man die length-Eigenschaft des option-Objektes auf 0 setzt.

Was habe ich bisher erreicht: ich habe auf der Serverseite schlanken überschaubaren Code, der vom Client direkt aufgerufen werden kann und ich habe auf der Clientseite Code, den ich mehrfach verwenden kann. Ich brauchte keine zig-Scripdateien zusätzlich einbinden, ich brauchte mich nicht darum zu kümmern, ob XMLRequest vom Browser überhaupt unterstützt wird, ich brauchte für die De-/Serialisierung der .NET-Objekte keine zusätzliche Zeile Code schreiben - ich habe mich in der Kommunikation zwischen dem Client und dem Server auf das Wesentliche beschränkt - dem Austausch von Daten. Ohne Updatepanel haben sich Teilbereiche meiner Seite verändert. Das grundsätzliche Vorgehen ist immer das gleiche - egal wie groß und komplex die Anwendung am Ende ist. Das ist es, was Ajax.Pro (und etwas Javascript) ausmacht.

Was in der Beispielanwendung noch fehlt, ist die Neuanlage eines Benutzers. Dabei ist die halbe Arbeit schon getan, ohne dass es uns dabei wirklich bewusst ist. Doch der Reihe nach.

Der Dropdownliste für die Anzeige der Benutzer wurde Eingangs ein onchange-Eventhandler zugewiesen. Dabei wurde die ID des Benutzers mit an den Server übergeben, in der Hoffnung, auch das entsprechende Benutzerobjekt vom Server zurück zu bekommen. Was ist aber, wenn kein Benutzer mit der übergebenen ID gefunden wurde? Aus diesem Grund hatte ich der Benutzerklasse zwei Konstruktoren spendiert, wobei der Standardkonstruktor eine neue Guid generiert und der id-Eigeneschaft zuweist und im übrigen alle weiteren Eigenschaften (Nachname, Vorname) einen Leerstring zuordnet. Der zweite Konstruktor ist mit dem id-Parameter ausgerüstet, um im Weiteren den Benutzer mit der übergebenen ID in der Datenquelle zu finden. Damit aber auch für den Fall, dass kein Benutzer in der Datenquelle gefunden wird, ein verwendbares Benutzerobjekt zurückgegeben wird, wurde sichergestellt, dass immer der Standardkonstruktor aufgerufen wird. Egal was passiert, es gibt immer ein Benutzerobjekt, das am Client weiter verarbeitet werden kann. Und genau diesen Umstand machen wir uns wieder zu nutze.

Also wird das Formular um einen Button zur Neuanlage eines Benutzers erweitert. Auch dieser Button wird mit einem onclick-Eventhandler ausgestattet, welcher über die Javascriptmethode AddBenutzer den Server aufruft. Damit bestehende Funktionalität genutzt werden kann, wird vorerst sichergestellt, dass die Dropdownlist auf den Index 0 gesetzt ist. Anschließend wird die Ajax-Servermethode GetBenutzer analog dem onchange-Eventhandler der Dropdownliste aufgerufen. Die übrige Vorgehensweise entspricht der des onchange-Eventhandlers. Da ich nun innerhalb des Callbackhandlers ein Formular erhalte, in dem nur die ID besetzt ist, kann ich die übrigen Felder ausfüllen und den Speichern-Button verwenden. Beim Speichen muss jedoch die serverseitige Ajax-Methode SaveBenutzer erweitert werden: Immer wenn das eigentliche Speichern des übergebenen Benutzerobjektes fehlschlägt, wird die Add-Methode der Benutzerklasse aufgerufen. Scheitert das Hinzufügen des Benutzers, so wird null zurückgegeben - in allen anderen Fällen die aktuelle Benutzerliste.

Und damit wäre ich am Ende meines kleinen Beispiels. Was man aber deutlich sehen kann ist, dass man mit Ajax.Pro seine Anwendung im Sinne des MVC-Pattern aufbauen kann, ohne dass man viel zusätzlichen Code schreiben müsste. Einzig Disziplin wird dem Entwickler abverlangt bei der Einhaltung des Konzeptes: keine Logik am Client, so wenig wie nötig Programmcode in den Ajax-Servermethoden - dafür ist die Businessschicht da. Ajax.Pro konzentriert sich auf den Austausch von Daten zwischen Client und Server. Es werden nur die Methoden aufgerufen, die auch tatsächlich in der Client-Server-Kommunikation unmittelbar benötigt werden. Und Ajax.Pro nutzt JSON intensiv, so dass nahezu beliebige .NET-Objekte zwischen dem Client und dem Server in beiden Richtungen ausgetauscht werden können.

Michael Schwarz hält auf seiner Webseite zu Ajax.Pro noch viele weitere interessante Beispiele bereit. Dieser Beitrag sollte mal in etwas anderer Form einen kleinen Einstieg in Ajax.Pro vermitteln. Wenn es die Zeit erlaubt, möchte ich in folgenden Beiträgen noch weiter zu Ajax.Pro schreiben und vor allem Lösungsideen aufzeigen, die sich mit Ajax im Allgemeinen umsetzen lassen - ganz ohne Updatepanel.

AJAX.PRO - eine der besten .NET AJAX-Bibliotheken

weblog@drescher-hackel.de (René Drescher-Hackel) — Thu, 02 Jul 2009 21:45:27 GMT

Kürzlich war im Netz zu lesen, was so alles an Bibliotheken in der Webentwicklung eingesetzt wird. Hierbei verwundert es nicht sonderlich, dass jQuery - wahrscheinlich auch durch die Ankündigung von Microsoft, jQuery in der nächsten Visual Studio Version von Haus aus zu unterstützen - derzeit einen regelrechten Hype in der ASP.NET Entwicklung erlebt.

Noch heute liest man in den Foren hier und da von der Ablehnung Javascript gegenüber, wobei die gleichen Entwickler sich auf das AjaxToolkit stürzen, wie der Löwe auf das Fleisch. Und dann liest man, wie stolz es doch so manch gestandenen Entwickler macht, wenn dieser erfährt, dass die von ihm ins Leben gerufene AJAX-Bibliothek sich nach wie vor wacker unter den vorderen Rängen hält.

Ich kann es eigentlich nicht oft genug wiederholen - wobei ich an dieser Stelle auch betonen muss, dass es meiner tiefsten überzeugung entspricht und keine allgemeine Lobhudelei darstellt - AJAX.PRO ist für mich seit Jahren die mit Abstand beste .NET Ajax-Bibliothek, die ich kenne.

Was macht AJAX.PRO für mich so interessant: Nun, keine andere Bibliothek ist so dicht am .NET, wie AJAX.PRO.
Ich kann hier .NET Objekte serialisieren (ohne selbst eine Zeile Code schreiben zu müssen, wie es doch in anderer Werbeaussage gern zitiert wird) zum Client senden und auch von diesem empfangen, ohne dass ich hier "wirklichen" Grenzen unterliege. Allein dieser Umstand ermöglichte uns in der Firma ein .NET Objektmodell am Client zu verwenden, so dass die Lernkurve extrem niedrig ausfiel. Der geneigte C#-Entwickler hat Javascriptcode gelesen und wusste sofort, was Sache war. Ist das nicht genial?

Dann kommt hinzu, dass sie sehr stabil läuft. Wir haben in der Firma mehr Probleme mit anderen Bibliotheken, wie z.B. dem AjaxToolkit, wo Probleme seit Jahren bekannt sind (und in Foren diskutiert werden, nebst Patch und Hack, um das Problem zu lösen), aber in aktuellen Releases nicht eingearbeitet werden. Und was AJAX.PRO eben auch ausmacht, im Vergleich zu allen anderen - hier wird sich auf das wesentliche konzentriert - dem Datenaustausch - ohne viel Schnickschnack.

Als ich kürzlich auf dem UG Event zu ASP.MVC von Albert Weinert war, staunte ich nicht schlecht, dass ASP.MVC nur JSON senden aber nicht empfangen kann - was soll ich damit anfangen. AJAX macht da erst richtig Spaß, wo die Kommunikation in beiden Richtungen - vorbehaltlos - stattfindet. Und das macht halt AJAX.PRO. Ich bedauere es ebenso nach wie vor, dass die öffentliche Entwicklung eingestellt wurde - AJAX.PRO ist und bleibt eine echte Bereicherung in der .NET Webentwicklung.

Ein alter Kollege hatte mal zu mir gesagt: "Ach AJAX.PRO ist viel zu aufgebläht, zu viel Ballast...". Das mag an einigen Stellen stimmen und auch wieder nicht. Denn eines darf man nie mit einander vergleichen: entwickle ich nur für einen Browser (IE) und im Intranet oder für eine Vielzahl von Anwendungsfällen im Internet - das ist es aber, was AJAX.PRO abdeckt. Insofern ist AJAX.PRO durchaus eine schlanke Bibliothek. Das "Abrutschen" in der Scala mag aus meiner Sicht zwei Ursachen haben: es wird (leider) nicht (öffentlich) weiter entwickelt und der eine oder andere tut sich schwer mit der Implementierung/Dokumentation.

Ich werde es jedenfalls weiter einsetzen - mit oder ohne Weiterentwicklung. Dafür ist AJAX.PRO einfach zu gut.

Ajax-Toolkit und die Webkit Browser

weblog@drescher-hackel.de (René Drescher-Hackel) — Thu, 25 Jun 2009 22:41:53 GMT

Heute habe ich nicht schlecht gestaunt, als ich mich wieder einmal intensiver als üblich mit dem Ajax-Toolkit auseinander gesetzt habe.
Ob man will oder nicht, hin und wieder ist man gezwungen gehalten Controls aus dem Ajax-Toolkit einzusetzen. Was man gerne dabei vergisst, ist die Tatsache,
dass das Toolkit weiterentwickelt wird.

Und so habe ich heute aus gegebenen Anlass die Assembly einmal aktualisiert - warum eigentlich nur??

Hintergrund des ganzen war ein Problem, welches ich hatte mit den Webkit-Browsern Safari und Chrome. Beide Browser hatten ein Problem damit, wenn man
Controls aus dem Ajax-Toolkit innerhalb eines Updatepanels lädt. Sicher wird der eine oder andere sagen: dann löse es anders, verzichte auf Updatepanel und Ajax-Toolkit. Ja, stimme ich voll zu, doch gelegentlich werden politische Entscheidungen getroffen, an denen dann nur schwer ein Weg vorbei führt - doch lassen wir dieses Thema. Es ist wie es ist und eine Lösung musste her.

Wie gesagt, die o.g. Webbrowser hatten gelegentlich ein Problem mit dieser Konstellation. Es schien, als würde der Webrequest nicht vollständig verarbeitet werden. Beim Debuggen und der ersten Fehleranalyse vor gut einem Jahr kam ich darauf, dass das Problem wohl in einem Scriptfehler irgendwo in den Scripten des Ajax-Toolkit liegt. Ich hatten nicht wirklich Lust, das weiter zu verfolgen - bis heute. Heute hat mich dann die ganze Angelegenheit wieder eingeholt - und ich muss sagen, am Ende waren es gerade mal knapp 2 Stunden Zeit, die ich investieren musste, um zu einer Lösung zu gelangen.

Was mich an der ganzen Geschichte am meisten aber ärgert ist, dass es denn keiner bislang geschafft hat, das Ajax-Toolkit in dieser Hinsicht gescheit zu aktualisieren.

Die Lösung fand ich letztlich im ASP.NET-Forum hier.
Eine kleine Scriptdatei mit folgendem Inhalt sollte man sich erstellen:

Sys.Browser.WebKit = {}; //Safari 3 is considered WebKit
if( navigator.userAgent.indexOf( 'WebKit/' ) > -1 ) {
    Sys.Browser.agent = Sys.Browser.WebKit;
    Sys.Browser.version = parseFloat( navigator.userAgent.match(/WebKit\/(\d+(\.\d+)?)/)[1]);
    Sys.Browser.name = 'WebKit';
}

Das Ganze dann im Scriptmanager wie folgt einbinden:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Scripts>
        <asp:ScriptReference Path="~/Scripts/Safari3AjaxHack.js" />
    </Scripts>
</asp:ScriptManager>

Fertig. Super!

Auf dem Weg zu dieser Lösung war ich auch schon dabei - wie oben erwähnt - das Ajax-Toolkit zu aktualisieren. Also aktuelle Version herunter geladen und eingebunden. Auch mal die Scripte geholt und über den Scriptmanager vom ScriptPath geladen. Hier kam dann die nächste Überraschung. Die Scripte passten in der Versionsnummer nicht zu der im Downloadbereich angebotenen Assembly. So kann das nicht funktionieren. Vielleicht bemerkt es ja mal jemand...

Am Ende dachte ich so: wie schön könnte AJAX sein, wenn man das alles nicht bräuchte...

Ajax Fileupload Fortschrittsanzeige

weblog@drescher-hackel.de (René Drescher-Hackel) — Fri, 05 Jun 2009 21:28:23 GMT

Wer sich mit dem Fileupload beschäftigt, steht irgendwann vor dem Problem, wie denn die Fortschrittsanzeige im Webbrowser sich umsetzen lässt.
Die Hardcorelösung wäre, den Benutzer auf die Anzeige in der Browserstatusanzeige zu verweisen. Die inzwischen häufigste Variante des Fileuploads besteht darin, für das Versenden der Datei ein iframe-Element zu verwenden. Zwar wird mitunter durch den Browser visuell signalisiert, dass sich da etwas tut, doch bekommt das der Benutzer jetzt noch weniger mit, wie beim Full-Postback der Seite.

Immer wieder trifft man im Netz auf Lösungen, die für die Zeit des Uploads eine animierte Grafik einblenden. Andere wiederum berechnen einen Uploadfortschritt auf Basis des für die Darstellung zur Verfügung stehenden Containers. Ist das Ende des Containers erreicht, fängt die Fortschrittsanzeige wieder von vorn an.

Worin besteht das Problem? Das iframe kann den Benutzer in der Regel informieren über den onload Event - doch dann hat aller Spuck oft ein Ende. Im Rahmen dieses Events beenden die meisten Entwickler die Darstellung ihrer Uploadanimationen.

Angeregt durch die Möglichkeiten, welche die Flashprogrammierung einem offenbaren, wollte ich einen halbwegs realistischen Uploadfortschritt im HTML mit Javascript realisieren. So suchte ich nach den Dingen, die mir letztlich zur Verfügung standen. Das waren

das iframe
der Uploadhandler (das document)

Für das document gibt es die Eigenschaft readyState - die, wie sollte es auch anders sein - kein Standard ist. Aber welche Informationen bietet mir diese Eigenschaft? Solange das document geladen wird ist der Wert loading oder (beim Opera-Browser) - interactive. Beide haben aber den Wert complete, wenn das document vollständig übertragen ist. Webbrowser, die diese Eigenschaft nicht unterstützen, muss man dann etwas austricksen. Nun braucht man eigentlich nur noch dafür zu sorgen, dass dieser Status regelmäßig geprüft wird. Die folgende Javascript-Methode zeigt einen möglichen Ansatz:

var iframeProgress = function(iframe, state, percent) {
    try {
          if (iframe[0].contentWindow) {
            var doc = iframe.contents();
            if (doc != undefined && doc.length == 1) {
                 var newstate = $.browser.msie ? doc[0].readyState : "loading";
                 if (newstate != state && newstate != "complete") {
                    if (percent < 98) {
                        // hier die Progressanzeige aktualisieren
                        setTimeout(function() { iframeProgress(iframe, state, percent += 2); }, 400);
                    }
                  }
             }
           }
        } catch (ex) { }
}

In dem Moment, wo der submit Event der Form getriggert wird, wird mit einer kleinen Verzögerung die Methode iframeProgress aufgerufen, der als Parameter das iframe-(jQuery)Objekt, der Status und die aktuellen Prozentwerte der übertragung mit übergeben werden. Das der Firefox z.B. die readyState - Eigenschaft nicht kennt, schiebe ich ihm diese einfach unter. Die Prüfung auf den Wert complete wird der Firefox ebenso nicht anders beantworten können, so dass die Prozentzahl um 2 erhöht und die Methode erneut aufgerufen wird. Dies passiert so lange, bis der onload Event des iframe selbst ausgelöst wird oder der fiktive Prozentwert 98 erreicht ist. Ich habe das Szenario mit Uploadgrößen von bis zu 47 MB getestet. Die Variation der Fortschrittsanzeige besteht im Verändern des Timeoutwertes und der Schrittweite des Hochzählens des Prozentwertes.

Am Ende kann man aber auf diesem Wege eine halbwegs realistische Fortschrittsanzeige im HTML mit Javascript realisieren.

Webslice - kann man implementieren - muss man aber nicht

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 01 Jun 2009 15:04:50 GMT

Durch einen Beitrag im dotnet-forum dazu ermuntert, habe ich mich nun mit der Erstellung und Implementierung von Webslices beschäftigt. Ich erspare mir an dieser Stelle, die Standarddefinitionen von Webslices in aller Ausführlichkeit zu wiederholen. Es gibt dazu genügend Fundstellen im Netz zu finden. Was ich mich allerdings gefragt habe war, wer braucht so etwas?

Diese Antwort lässt sich wohl nie abschließend klären, zumal es ohnehin eine Funktionalität ist, die derzeit nur in einem Browser, dem Internet Explorer 8, funktioniert. Wer aber jeden Trend auf seiner Webseite mit machen will, für den lohnt es sich, dass er sich mit diesem Thema einmal auseinander setzt. Doch wie implementiert man nun einen Webslice.

Im Internet fand ich zu diesem Thema zwei recht gute Beschreibungen. Zum einen hat sich Klaus Bock damit in seinem Weblog befasst und auch Daron Yöndem.

Im Wesentlichen reduziert sich die Definition von Webslices auf einen DIV Container mit mindestens einem bzw. zwei weiteren Child-Elementen. Was als Webslice vom Browser dabei erkannt und wie deren Funktionalität umgesetzt wird, bestimmen die Css-Klassennamen der Elemente. Für das Basiselement ist dabei der Klassenname hslice zwingend. Als erstes Child-Element folgt in der Regel ein den Titel bestimmenden Container. Hierbei kann man nahezu jedes HTML-Element verwenden, wobei H1, DIV oder SPAN-Elemente am sinnvollsten erscheinen. Das Titel-Element erhält dann den Css-Klassennamen entry-title. Das, was innerhalb des Titel-Tags angeben wird, verarbeitet der Browser dann in der Anzeige des Webslice. Das Titel-Element kann man in der Regel ausblenden mit der style-Anweisung "display:none" (dazu weiter unten mehr).
Das zweite Element beinhaltet den eigentlichen Content. Hier sollte man ein DIV-Element wählen und muss diesem den Css-Klassennamen entry-content zuweisen. Innerhalb dieses Containers kann man seinen HTML-Phantasien freien Lauf lasen, sprich gültiges HTML ist zulässig.

Also wenn man es sich recht betrachtet, ist es nicht wirklich viel Aufwand. Damit das ganze nun auch brav vom Browser erkannt wird, bedarf es noch einer Erweiterung im Head-Tag der Seite. Hierzu wird ein Link-Tag eingefügt, welches die Attribute rel mit dem Wert default-slice, type mit dem Wert application/x-hatom und href haben muss. Der Wert für das href Attribute ist dabei die ClientID des DIV-Containers, der den Css-Klassennamen hslice zugewiesen bekommen hat. Möchte man mehrere Webslices auf der Seite platzieren, so muss für jeden Webslice ein separater Link-Tag im Head der Seite vorhanden sein.

Hat man alles richtig gemacht, dankt es der Internet Explorer 8 mit einem kleinen grünen Symbol.

Wie Klaus und Daron schon beschrieben haben, kann man den Content des Webslice auch über eine separate Seite organisieren oder z.B. bei Verwendung innerhalb einer Masterpage über diese, wobei der hslice-Container standardmäßig nicht sichtbar ist bzw. sein sollte.

In meinem Fall habe ich mich dafür entschieden, den Webslice entsprechend der darzustellenden Aufgabe sichtbar innerhalb des Seiteninhaltes zu platzieren. Der Webslice soll dabei immer den zuletzt veröffentlichten Beitrag darstellen. Die Vorgehensweise entspricht der oben beschriebenen, wobei es wichtig war, das HTML-Element mit dem Titel des Webslice auszublenden, da er sich sonst nicht in das bestehende Layout der Seite integrieren ließe. Ein weiterer Nebeneffekt bei dieser Form der Implementierung liegt in der Darstellung des Webslice selbst. Will man den Blogbeitrag weiterlesen, so muss man zwangsläufig mit der Mouse über den hslice-Container sich bewegen. In genau diesem Moment erscheinen ein grüner Rahmen und das Webslice-Icon. Durch Anklicken des Icons kann man diesen Webslice abonnieren.

Nachteilig an den gesamten Webslice-Implementierungsmöglichkeiten finde ich jedoch die unzureichende Art der Nutzung von Javascript. Hier hätte ich mir mehr Möglichkeiten vorstellen können. Weiterhin habe ich noch keine Möglichkeit gefunden, dass der Flayout-Container scrollbar ist.
Vorteilhaft finde ich, dass trotz der Insellösung, nach der Implementierung die Seite immer noch den Anforderungen des W3C entspricht. Ebenso von Vorteil ist es, dass man das CSS des Webslice so gestalten kann, dass es noch an die Ursprungsseite erinnert und nicht nur einfache Links mit etwas Text möglich sind.

Unterm Strich kann man sagen: kann man haben - muss man aber nicht (vor allem, weil es nur derzeit in einem Webbrowser funktioniert).

Auch das Kleingedruckte sollte man immer lesen

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 16 May 2009 20:32:25 GMT

Gewinnspiele sind sicherlich nett, wenn man denn etwas gewinnt. Den Sinn eines Gewinnspieles darf man mitunter nicht näher hinterfragen. So ist es auch bei folgendem Gewinnspiel. So las ich kürzlich im Weblog von Jan Welker, dass ein jemand etwas verlost, wenn man sich denn offenbart und seine drei liebsten Entwicklertool benennt und vielleicht auch noch zwei Sätze, warum dies so ist.

Ja, da kann man wohl teilnehmen, dachte ich mir so... Dann las ich mal die Teilnahmebedingungen, denn schließlich geht nichts in diesem Land, ohne ordentliche Bedingungen. ;-)

Und unter Punkt 11 stand dann, dass Gewährleistungsansprüche hinsichtlich der Gewinne ... ausgeschlossen sind.

Ups - gewinne ich etwas, was möglicherweise mal kaput gehen könnte, dann darf ich es gleich in die Tonne schmeißen, da ja Punkt 11 gilt. Also auf Ideen kommen die Leute...

Doch zurück zum Thema. Von abgesehen, dass der potentiell in Aussicht gestellt Gewinn mich eher weniger reizt (das demnächst auf den Markt kommende Betriebssystem wäre da sicher interessanter ;-)),

so sind meine drei Favoriten:

Visual Studio
Sourcesafe
Notepad

Mit Visual Studio arbeite ich von anbeginn (früher noch als Interdev ). Warum ich es schätze: nun, ich könnte nicht alle Vorzüge hier aufzählen, doch hat es über Jahre hinweg mir stehts die Arbeit erleichert - es sind die vielen kleinen Helferlein, die in diesem Programm stecken (auch wenn es mich gelegentlich wahnsinnig macht, wie aktuell die Initialisierung der Toolbox, wenn man das erste Mal eine Datei öffnet).

Sourcesafe ist unverzichtbarer Bestandteil meiner täglichen Arbeit, welches sich ebensogut ins Visual Studio integriert.

Notepad: nun, hin und wieder geht es nicht ohne - es ist der beste "Schmierzettel" am PC.

Ajax Fileupload

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 02 May 2009 20:40:39 GMT

Wer sich mit der Entwicklung von Webanwendungen beschäftigt, kommt sicher nicht umhin, auch einmal ein Upload-Formular zu erstellen. In Zeiten des "Web 2.0" (wofür diese Bezeichnung auch immer stehen mag) werden die Wünsche und Ideen auch immer anspruchsvoller. Und so verwunderte es nicht all zu sehr, dass mit dem AJAX-Hype der Gedanke aufkam, so ein schönen Dateiupload per AJAX zu erledigen. Es folgte ziemlich schnell die Erkenntnis, dass dies nicht geht und wahrscheinlich auch künftig so nicht gehen wird, will man sich auf den klassischen XML-Request beschränken.

Eine schon vor dem AJAX-Hype viel genutzte Variante war, die Datei, die zum Server zu übertragen ist, über ein nicht sichtbares Frame zu senden. Anfänglich wurde hierzu das Frameset genutzt, wobei ein Frame mit 0 definiert wurde, so dass der dort stattfindende Request für den Benutzer der Seite verborgen blieb. In der Folgezeit ging man jedoch immer mehr dazu über, das iframe-Element zu nutzen.

Dies ist bis heute die wohl weit verbreiteste Form der "versteckten" Hintergrundübertragung von Datein zum Server. Und genau vor diesem Hintergrund machte ich mich die Tage auf, das Netz zu durchforsten, was es an Ideen schon gibt, so dass man einen - sagen wir mal kompfortablen - Dateiupload erstellen kann.

Die aus meiner Sicht vielversprechendste Lösung bot sich bei Andrew Valums, der ein entsprechendes Javascript unter der MIT-License veröffentlicht hat. Vieles, was diese Lösung bietet, ist eigentlich genau das, was man sich - will man es denn so bezeichnen - unter einem AJAX-Upload vorstellt. Andrew hat dabei den Einsatz mit prototype als auch jQuery berücksichtigt. Besonders gelungen ist auch meiner Sicht, die Umsetzung des Klickevents zum Anzeigen des input-File-Dialoges. Hierbei wird die Mausbewegung im document überwacht und sobald sich die Maus über dem Bereich befindet, der den eigentlichen Dialog öffnen soll, wird das nicht sichtbare input-File-Element unter dem Mauszeiger plaziert. Ein jetzt erfolgender Klick führt somit immer zum Öffnen des File-Dialoges.

Da über die CSS-Attribute des input-File-Elementes dieses vollständig unsichtbar gemacht werden kann, bekommt der Benutzer von diesem Verhalten nichts mit.
Nachteilig an der Version von Andrew ist jedoch, dass beim Verlassen des Bereiches das input-File-Element noch mitwandert und ich faktisch auch ausserhalb meines eigentlich gedachten Upload-Bereiches den File-Dialog öffnen könnte. Derartiges kann bei Benutzern leicht zu Irritationen führen. Die Lösung liegt derweil auf der Hand - man positioniert einfach das input-File-Element außerhalb des sichtbaren Bereiches.

Weiter positiv in der Umsetzung fand ich, dass die drei klassischen Eventhandler mit implementiert sind.

Als erstes kann man auf der Anwendungseite reagieren, sobald eine Datei über den File-Dialog ausgewählt wurde. Als Parameter gibt Andrew dann den Dateinamen als auch die Dateierweiterung mit.
Ein weiteres Mal kann vor dem Absenden der Datei zum Server noch einmal auf Anwendungsseite reagiert werden, wobei auch hier der Dateiname und die Dateierweiterung als Parameter zur Verfügung stehen. Zu guter Letzt kann man entsprechend noch reagieren, wenn dann die Datei zum Server übertragen wurde, der eigentliche Upload also fertig ist.

Muss man im Zusammenhang mit dem Dateiupload noch weitere Daten zum Server mit übertragen, so kann man über das option-Objekt bei der Initialisierung ein data-Objekt mit angebengeben. Bei der Vorbereitung des Postbacks werden dann entsprechende input-Hidden-Elemente angelegt und mit zum Server übertragen.

Eines hatte ich jedoch vermisst. Was passiert eigentlich, wenn ich einen Multifileupload mit dieser Lösung umsetzen möchte. Eigentlich passte soweit alles, bis ich eine Datei auswählte, die in der Liste schon vorhanden war. Im onComplete-Eventhandler jetzt die Datei allein über den Namen zu identifiezieren war zum Scheitern verurteilt. Ich brauchte also einen Key, der im onChange-Eventhandler schon zur Verfügung stand, so dass ich diesen auf Anwendungsseite verarbeiten konnte, um dann bei Abschluss des Uploads den richtigen Eintrag in der Liste wiederzufinden. Schön wäre, wenn es soetwas wie eine GUID im Javascript gäbe.

Hier fand ich dann eine Lösung, die mir hier weiterhelfen sollte.
Sicher gibt es auch andere, vielleicht auch einfachere Lösungsansäntze (string + counter) für mein Problem mit dem Key, doch schwebte mir in der Tat dieser GUID-Gedanke im Kopf, so dass ich diese letztlich favorisierte. Also baute ich mir schnell ein GUID-Objekt, und modifizierte den Rückgabeparameter in den Eventhandlern entsprechend.

Das eigentliche Senden der Datei erfolgt dann auch wieder über ein für den Benutzer nicht sichtbares iframe-Element. Gut fand ich auch in diesem Zusammenhang, das Andrew sich auch das entsprechend für den Dateiversandt erforderliche Formular gekümmert und ein separates form-Element mit dem entsprechenden enctype-Attribute (enctype="multipart/form-data") angelegt hat.

Insgesamt eine runde Sache, die Andrew mit seinem Javascript hier erstellt hat.

Da ich prototype nicht einsetze, habe ich die Scriptdatei für meine Bedürfnisse angepasst und stärker dem Umstand Rechnung getragen, dass in meinen Projekten jQuery zum Einsatz kommt.
Andrew setzt hingegen kein spezielles Framework voraus.

Barrierefrei, W3C-Konform und andere Wünsche

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 27 Apr 2009 23:42:04 GMT

Wenn man als Webentwickler sich dabei macht und eine neue Anwendung plant, dann kommen viele Wünsche auf. Als letztes denkt man aber an die strikte Einhaltung von bestimmten Standards. So habe ich mir mit der Neugestaltung des Weblogs das Ziel gesetzt, die W3C-Standards strikt einzuhalten und nach Möglichkeit barrierefrei zu sein.

Andererseits mochte ich nicht auf die so lieb gewonnenen Javascriptfunktionalitäten wie AJAX und jQuery verzichten. Auch hatte ich dabei im Blick, wie wohl so manch Suchmaschine die Seite am besten durchsuchen und indizieren kann.

Was die Suchmaschine angeht, hab ich eine Lösung bei Thomas Bandt und Albert Weinert gefunden, die das Projekt URL-Rewriting in hervoragender Art und Weise umgesetzt bzw. erweitert und vor allem beschrieben haben. Damit war es möglich - ohne all zu tief in die Materie des Urlrewriting einsteigen zu müssen - die einzelnen Seitenlinks suchmaschinenfreundlich zu gestalten.

Ein weiterer Effekt, der sich dadurch ergeben hat, war die Sache mit dem AJAX. Durch einen einfachen Klickevent konnte ich den Linkklick so gestalten, dass - wenn Javascript aktiv ist - der Inhalt partiell über AJAX (AJAX.PRO) und jQuery aktualisiert wird. In allen anderen Fällen, wird dann einfach der Get-Aufruf der verlinkten Adresse ausgeführt.

Eine andere Herausforderung bestand in der Umsetzung der Barrierefreiheit. Hier war zunächst die Frage nach einem WCAG-Validator, möchte man nicht am Ende selbst die Prüflisten abarbeiten. Ich habe mich dabei für die Seite liavaag.org entschieden.

Unterm Strich muss ich sagen, war sicher einiges etwas nervig bei der Umsetzung der Barrierefreiheit (z.B. dass es nicht mehr ein einfacher "weiter..." - Link reicht, nein der Text muss für alle Links verschieden sein. Oder dass fast jedes Element ein tabindex-Attribute benötigt. Lustig wird die Sache , wenn man dann mit dynamischen Listen arbeitet.

Bei der Einhaltung der CSS-Standards war mir diesmal wichtig, dass von den Webdesignern ja immer wieder geforderte Umsetzen von Layout ohne Tabellen. In meiner täglichen Arbeit erfahre ich dabei immer wieder, wie schnell man doch dabei ist und eine Tabelle nimmt, weil es sich doch damit so schön alles anordnen lässt. Ich muss zugeben, es ist schon manchmal ein ganz schöner "Beinbruch" will man alles mit div-Elementen umsetzen. Andererseits, hält man nur ein paar kleine Regeln ein, wie z.B. dass jedes div-Element, das floaten soll, auch bitte eine Breite zugewiesen bekommen muss, dann ist es am Ende fast nur halb so schwierig. Unverzichtbare Ressource dabei die Seite css4you.

Am Ende kann ich nur jeden ermutigen, sich bei der Umsetzung von Webprojekten an die geltenden Standards zu orientieren - dann hat man es auch einfacher mit der Browserkompatibilität.

jQuery und der liebe Cache

weblog@drescher-hackel.de (René Drescher-Hackel) — Fri, 24 Apr 2009 20:38:13 GMT

In einem aktuellen Projekt hat mich $.cache von jQuery schon so manches Mal zur Verzweiflung gebracht. Man hat sich gefreut, dass mit jQuery jetzt vieles einfacher und vor allem schneller geht. Als die Anwendung dann im Internet Explorer einige Zeit lief, folgte die Ernüchterung auf dem Fuße, was die Perfomance angeht. Letztlich war guter Rat gefragt und eine Lösung irgendwie nicht in Sicht.

Klar war, dass alle Events, die einmal gebunden wurden auch wieder mit unbind freigegeben werden müssen. Dennoch brachte es keine dauerhafte Verbesserung. Nach einiger Zeit des Debuggens kam mir das Objekt $.cache unter die Finger. Die Radikallösung

$.cache = {}

wird indes nicht empfohlen. Ich hab es dennoch ausprobiert - es ist in der Tat nicht empfehlenswert.
Doch wie geht es weiter? Die Lösung war so nah vor Augen. Man braucht nur die leeren Objekte im $.cache - Objekt zu löschen. Also habe ich mir eine kleine Methode hierzu geschrieben, die dann auch bitte gleich das unbind der Events mit erledigt.

Die Methode übernimmt dabei zwei Argumente - zum einen den Selektor, der für den unbind-Aufruf erforderlich ist und zum anderen ein String-Array von Eventnamen.
Im nächsten Schritt wird das $.cache-Objekt durchlaufen und immer wenn keine Eigenschaften zum Objekt vorhanden sind - es also leer ist - dann wird das betreffende Objekt gelöscht.

Statt des Aufrufes von

$("input, select").unbind("keyup").unbind("change");

nutze ich die o.g. Methode,

clear$Cache("input, select", ["keyup","change"]);

da hier das jQuery-Cache-Objekt bereinigt wird - zum Vorteil der Webanwendung.

Reguläre Ausdrücke

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 20 Apr 2009 22:00:20 GMT

Im Artikel vom 18.04.2009 hatte ich einen DHTML-Editor vorgestellt. So gut die dort genannte Lösung ist, so kommt man um kleinere individuelle Anpassungen und Erweiterungen nicht herum.Eine gute Hilfe sind hierbei Reguläre Ausdrücke.

Das Problem, das immer mal wieder auftaucht ist, dass der im Editmode erzeugte HTML-Code oft nicht valide im Sinne des W3C ist. Entweder sind die Tags großgeschrieben, oder die Attribute erhalten Zuweisungen, ohne dass diese in Hochkommatas eingefasst werden. Vor diesem Problem stand ich unlängst.

Mit der folgenden Anweisung habe ich den HTML-Text durchsucht und die relevanten Passagen ersetzt.

            Regex reg = new Regex(@"</?[A-Za-z]+[^>]*>");
            MatchCollection mc = reg.Matches(htmlSource);
            foreach (Match m in mc)
            {
                string value = m.Value;
                Regex reg2 = new Regex("[A-Za-z]+[=]{1}[\"\']?\\s?[A-Za-z0-9\\;\\.?\\:?/-]+\\s?[\"\']?");
                MatchCollection mc2 = reg2.Matches(value);
                foreach (Match m2 in mc2)
                {
                    string value2 = m2.Value;
                    string[] v = value2.Split('=');
                    value = value.Replace(value2,string.Format("{0}=\"{1}\"", v[0], v[1].Replace("\"", "").Replace("'", "")));
                }

                htmlSource = htmlSource.Replace(m.Value, value.ToLower());
            }

Der erste Ausdruck ermittelt dabei den HTML-Tag. Der zweite Ausdruck ermittelt alle Attribute innerhalb des HTML-Tags. Der Rest sind dann nur einfache Stringoperationen.

Es macht sich also bezahlt, sich hin und wieder mit Regulären Ausdrücken zu beschäftigen.

Texthighlight mit jQuery

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 19 Apr 2009 23:26:32 GMT

Johann Burkhard hat ein interessantes jQuery-Plugin entwickelt und unter der MIT-License veröffentlicht, mit dem es möglich ist, bestimmte Textpassagen farblich hervorzuheben. Anwendungsgebiete gibt es hierzu reichlich, ich denke dabei nur an die Suchfunktion auf einer Webseite. Häufig werden mehrere Fundstellen zur formulierten Suchanfrage ausgeben, doch verliert man den Überblick und bei mancher Fundstelle fragt man sich, "was hatte das mit meiner Anfrage zu tun gehabt". In solchen Fällen ist es hilfreich für den Suchenden, wenn seine Anfrage in der Fundstelle farblich hervorgehoben wird.

Die Implementierung ist dabei - wie fast immer bei jQuery-Plugins - denkbar einfach:

Man fügt zunächst die Javascriptdatei seinem Projekt und resp. seiner Webseite hinzu. Dann erfolgt die Auswahl des Containers innerhalb dessen die Textmarkierung erfolgen soll. Auf diese Auswahl ruft man die Methode highlight auf und über gibt den zu markierenden Text als Argument.

Ich habe dieses Plugin in diesem Blog implementiert. Wer also die praktische Seite sich ansehen möchte, benutze hier einfach die Suche.

Einzig im Plugin habe ich eine kleine Ergänzung vornehmen müssen, nämlich wenn ein Leerstring als Argument übergeben wird. Für diesen Fall muss die Methode verlassen werden. So habe ich im Plugin folgende Zeile hinzugefügt:

jQuery.fn.highlight = function(pat) {
if (pat == "") { return this; }
...

Und zu guter Letzt: es funktioniert in allen Browsern, die jQuery unterstützen.

jQuery 1.3 Cheat Sheet

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 18 Apr 2009 21:36:13 GMT

Jürgen Gutsch hat mich mal wieder auf dem Laufenden gehalten. Es ist halt immer wieder gut, das eine oder andere Weblog regelmäßig zu lesen.

So hat sich wieder einmal jemand die Mühe gemacht und einen kleinen 2 Seiten umfassenden Spickzettel zum jQuery 1.3 verfasst. Interessant ist dabei, welche Übersichten noch verfügbar sind.

Für die tägliche Arbeit sind diese Cheat Sheets immer wieder eine gute Hilfe.

DHTML Editor einmal anders

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 18 Apr 2009 21:16:00 GMT

Die ganzen Tage hatte mich geplagt, dass ich noch keine gescheite Oberfläche hatte, um den Weblog zu bedienen, sprich Einträge hinzuzufügen, zu editieren oder gar zu löschen. Sicher gibt es DHTML Editoren auf Webbasis (hab mir sogar eine Lizenz gekauft gehabt), so richtig konnte ich das ganze nicht so nutzen, wie ich es mir vorgestellt hatte.

Also dachte ich mir, es muss doch was machbar sein im Rahmen einer Windows-Applikation. Codeproject gehört dabei bei mir seit Jahren mit zur ersten Anlaufstelle, denn fast alles, was einem heute so in den Kopf kommt, wurde auf dieser Welt schon einmal gedacht, entworfen, entwickelt, etc. Also warum sollte man das Rad stets neu erfinden.

Und in der Tat gab es einige Fundstellen, wobei mir diese am meisten zusagte. Sie ist verständlich aufgebaut, erweiterbar und in C# geschrieben - alles, was ich gesucht hatte.

jQuery - Praktischer Einsatz (1)

weblog@drescher-hackel.de (René Drescher-Hackel) — Wed, 01 Apr 2009 22:54:04 GMT

Ich muss zugestehen, es ist nicht jQuery, das es möglich macht, sondern eher das Verständnis für Javascript. Ich muss schon des öfteren Schmunzeln, wenn ich lese "viel clientseitige Funktionalität, aber bitte ohne Javascript". Ich hab keine Ahnung, wer sich das ausdenkt, doch gehört Javascript heute zur Webanwendung, wie die Butter zum Brot.

Michael Schwarz hat in seinem Blog zB. eine Möglichkeit aufgezeigt, wie einfach und praktisch man clientseitige Events (besser) verwalten kann.

Hierzu wird der Event nicht auf dem einzenlen Element registriert, sondern auf dem "Mutterelement". Der Rest läst sich einfach dann ermitteln. Einzigst die Eigenschaft srcElement wird offenbar im jQuery nicht ganz konsquent durchgesetzt. So führt deren Verwendung mit dem Netscape-Browser zu einem Scriptfehler. Ich habe mich daher auf die target Eigenschaft festgelegt, welche bislang in allen Browsern fehlerfrei interpretiert wurde. Ein weiterer Vorteil liegt letztlich auch in der Administration und Wartbarkeit der Events.

Angeregt von Michael s Beitrag, hab ich mich die Tage mit einem "WebControl" beschäftigt, was an sich keines ist, da es nahezu vollständig über Javascript realisiert wird. Ausgangssituation ist hier ein JSON-String.

 <script type='javascript' >
 var daten = {
 Elements : [
 { Name : "Element 1", Elements : [ "E1 Wert 1","E1 Wert 2","E1 Wert 3","E1 Wert 4" ] },
 { Name : "Element 2", Elements : [ "E2 Wert 1","E2 Wert 2","E2 Wert 3","E2 Wert 4" ] },
 { Name : "Element 3", Elements : [ "E3 Wert 1","E3 Wert 2","E3 Wert 3","E3 Wert 4" ] }
 ]
 };
 <\script>

Um das ganze dann auch ausgeben zu können, kann man das Object daten um eine Methode, die ich mal getTree genannt habe, erweitern.

Hierbei prüft man gescheiterweise, ob man nicht schon einmal die ganze Arbeit des Rendern geleistet hat. Daher ist es ratsam, das treeView-Element vorher zu selektieren und dann gegebenenfalls z.B. nur einzublenden. Ist das "Grundgerüst" noch nicht am Server vorhanden, erstellt man es und bindet zugleich den "einzigen" Click-Eventhandler an das Object.

 var div = $("<div id='treeView' ><div id='treeViewContent' /></div>")

Im Click-Eventhandler ermittelt man dann u.a. mit der vom Michael Schawrz veröffentlichten Methode das eigentliche Eventelement und nimmt die weitere Verarbeitung vor, in diesem Fall, das Rendern und Anzeigen der Unterknoten.

 .bind("click", function(ev) {
 var ele = $(ev.target);
 var e = findParent(ele, "div[:parent=#treeViewContent]", 9);
 var name = e.find("a").text();
 
 if (e.attr("name") != undefined
 && e.attr("name") == "subNode") {
 //mach was...
 return false;
 } else if (e.parent().attr("id") == "treeViewContent") {
 var img = e.find("img");
 var subNode = $("#sub" + name); if (img.attr("src").endWidth("plusnode.png")) {
 img.attr("src", "images/minusnode.png");
 e.toggleClass("parentNodeSelect");
 var o = json.Elements.getByName(name);
 if (subNode.length == 0) {
 var sub = $("<div style='clear:both; width:auto;' id='sub" + name + "' />")
 .css({ overflow: "hidden" });
 var on = o.Elements.length;
 for (var s = 0; s < on; s++) {
 var _s = $("<div class='treeNode' name='subNode' ><a>" + o.Elements[s] + "</a></div>");
 _s.appendTo(sub);
 }
 sub.insertAfter(e);
 } else {
 subNode.show();
 }
 }
 else {
 img.attr("src", "images/plusnode.png");
 e.toggleClass("parentNodeSelect");
 subNode.hide();
 }
 } else {
 return false;
 }
 });

Hat man alles richtig gemacht, erhält man folgende Anzeige:

Dies Sample lässt viele Möglichkeiten offen. In einem aktuellen Projekt habe ich so zum Beispiel dies als Grundlage dafür genommen, um in einer Client-Server-Kommunikation ganz auf das Update-Panel zu verzichten. Was soll ich sagen, es funktioniert.

Ebenso kann man dieses Sample dahin erweitern, dass man z.B. Tabellenansichten umsetzt oder gar eine Filterfunktion für die Treeview-Selektion implementiert.

Interessant ist hierbei der Einsatz von jLINQ. jLINQ ist dabei eine interessante jQuery-Implementierung von .NET LINQ im Javascript-Umfeld. Als Datenbasis dient ein Array von Objekten, auf die dann die Afrage ausgeführt werden kann.

Mit Javascript Zahlen mit Tausender Trennzeichen

weblog@drescher-hackel.de (René Drescher-Hackel) — Tue, 10 Mar 2009 13:33:02 GMT

Wie kann man mit Javascript Zahlenwerte in einer Textbox (input-Element) so formatieren, dass sie mit einem Tausender-Trennpunkt angezeigt werden?

Hierzu kann man sich eine prototype-Methode zum String-Objekt schreiben.

Der Ansatz ist recht einfach eigentlich - man zerlegt einfach den String immer wieder in 3 Zeichen große Teile und legt diese in einem Array ab. Anschließend rollt man das Array von hinten auf, macht noch zwei Ersetzungen und fertig ist es.

String.prototype.toLocaleFormat = function() {
    var n = this;
    ns = String(n).replace('.', ',');
    var w = [];
    while (ns.length > 0) {
        var a = ns.length;
        if (a >= 3) {
            s = ns.substr(a - 3);
            ns = ns.substr(0, a - 3);
        } else {
            s = ns;
            ns = "";
        }
        w.push(s);
    }
    for (i = w.length - 1; i >= 0; i--) {
        ns += w[i] + ".";
    }
    ns = ns.substr(0, ns.length - 1);
    return ns.replace(/\.,/, ',');
}

MSDN Premium mit Visual Studio abzugeben

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 28 Feb 2009 22:27:18 GMT

Wer es noch nicht hat, für den ist es eine interessante Möglichkeit.
Michael Schwarz hat über seinen Weblog eine MSDN Premium abzugeben.

Na dann viel Glück ;-)

Ein neuer Anfang

weblog@drescher-hackel.de (René Drescher-Hackel) — Sat, 28 Feb 2009 12:43:02 GMT

So langsam geht es der Fertigstellung des neuen Weblogs entgegen. Durch eine Unachtamkeit beim Öffnen der Webseite mit dem Visual Studio 2008 hatte ich versehentlich meinen eingerichteten Weblog mit einem Mouse-Click gewissermaßen "abgeschaltet".

Nun dachte ich, nicht so schlimm - aktualisiere ich ebend auf die neuste Version von dasblog. Aber - zu früh gefreut. Aufgrund der doch eigenwilligen anderen Sicherheitskonfigurationen von dasblog kann ich es im Medium-Trust Umfeld des Hosters so nicht betreiben.

Also habe ich mir die Content-XML-Datei gesichert und eine eigene Anwendung geschrieben. Die bisherigen Inhalte werde ich dann nach und nach wieder einspielen.

Also dann - wieder viel Spaß beim Lesen... ;-)

Der Weg zum WYSIWYG - Editor

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 29 Dec 2008 23:06:16 GMT

Immer häufiger lese ich im Netz, dass die Anforderungen an WYSIWYG Editoren immer öfter von den
vorhandenen Standardlösungen nicht bedient werden können. Hier hilft letztlich nur noch, den
bestehenden Editor seiner Wahl im Rahmen der bestehenden Lizenzbedingungen anzupassen oder gleich
selbst sich einen Editor zu erstellen, der genau diesen Anforderungen genügt.

Unerlässlich ist dabei jedoch die Bereitschaft, sich mit den Möglichkeiten von Javascript in seiner
Webanwendung vertraut zu machen. Als wichtige Referenz sollte man zudem folgende Adresse im Auge
behalten: http://msdn.microsoft.com/en-us/library/ms533049(VS.85).aspx

jQuery-Ansatz für transparente PNG Grafiken im Internet Explorer 6

weblog@drescher-hackel.de (René Drescher-Hackel) — Wed, 10 Dec 2008 20:48:18 GMT

Im Blog-Beitrag hatte ich einen jQuery-Ansatz aufgezeigt, wie man PNG-Grafiken im Internet Explorer < 7 transparent darstellen kann. Möglich wurde dies durch die Unterstützung des filter-Attributes.
Doch wie sieht das ganze aus, wenn man PNG-Hintergrundgrafiken einsetzt und diese zB einen transparenten Verlauf haben.
Hier könnte man wieder die scriptseitige Implementierung wählen:

<script type="text/javascript">
$(document).ready(function() {
  if ($.browser.msie) {
   $(".transpPNG").each(function() {
   var img = this.currentStyle.backgroundImage.substr(5).replace("\")", "");
   $(this).css({ background: "none",
         filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+img+"', sizingMethod='scale')" });
   });
}
} );
</script>

Hier wurde eine Selektion auf alle DIV-Elemente mit dem class-Attribute "transpPNG" vorgenommen und die filter-Eigenschaft gesetzt. Wichtig zu wissen ist dabei, dass die background-Eigenschaft auf 'none' gesetzt werden muss. Die Bild-Url wird dabei aus den aktuellen Css-Definitionen ermittelt.
Als jQuery-Erweiterung ergäbe sich dann folgender Code:

<script type="text/javascript">

$(document).ready(function() {
if ($.browser.msie) {
$(".transpPNG").setTransparentBackground(); }
});

$.fn.setTransparentBackground = function() {
return this.each(function() {
  var img = this.currentStyle.backgroundImage.substr(5).replace("\")", "");
  $(this).css({ background: "none",
        filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+img+"', sizingMethod='scale')"
  });
});
}
</script>

Drucken mit jQuery

weblog@drescher-hackel.de (René Drescher-Hackel) — Fri, 26 Sep 2008 22:20:14 GMT

Drucken von Webseiteninhalten ist immer ein zweischneidiges Schwert. Oftmals möchte man nur bestimmte Bereiche der Seite nur drucken.

Das jQuery Plugin PrintArea bietet hier einen interessanten Ansatz. Hier wird über ein nicht sichtbares IFrame der selektierte Content der Webseite ausgedruckt.
Wenn man sich dann noch bei macht und innerhalb des Plugins das jQuery - Konzept verfolgt, erhält man dann folgende Erweiterung, die das Ausdrucken von Teilbereichen der Webseite deutlich vereinfacht.

$.fn.printArea = function() {
       var ele = $(this);
       var counter = 0;
       $("iframe[@id^='printArea']").remove();
       return this.each(function(e) {
           counter++;
           var iframe = $('<iframe />') .css({
               position: 'absolute',
               width: '0px',
               height: '0px',
               left: '-500px',
               top: '-500px' })
         .attr('id', "printArea_" + counter)
         .appendTo($("body"));
  var doc = iframe.get(0).contentWindow.document;
  $("link").each(function(e) {
  if (this.rel.toLowerCase() == 'stylesheet')
   doc.write('<link type="text/css" rel="stylesheet" href="' + this.href + '"></link>');
  });

doc.write('<div class="' + ele.attr("class") + '">' + ele.html() + '</div>');
doc.close();
$(doc.body).css({ backgroundColor: '#fff' });
  iframe.get(0).contentWindow.focus();
setTimeout(function() { iframe.get(0).contentWindow.print(); }, 10);
}); }

Zunächst werden bei jedem Aufruf alle im DOM noch vorhandenen IFrames, deren ID-Attribute mit printArea beginnt, aus dem DOM entfernt.

$("iframe[@id^='printArea']").remove();

Im nächsten Schritt werden für alle auf der Selektion gefundenen Bereiche jeweils ein separates IFrame erzeugt und dem Body-Element hinzugefügt.

var iframe = $('<iframe />') .css({ position: 'absolute', width: '0px', height: '0px', left: '-500px', top: '-500px' }) .attr('id', "printArea_" + counter) .appendTo($("body"));

Über den Eingangs definierten Counter erhält jedes IFrame dabei seine eindeutige ID. Im nächsten Schritt wird dann das CSS der Basisseite übernommen in das Document des IFrames.

var doc = iframe.get(0).contentWindow.document; $("link").each(function(e) { if (this.rel.toLowerCase() == 'stylesheet') doc.write('<link type="text/css" rel="stylesheet" href="' + this.href + '"></link>'); });

Anschließend muss noch der Inhalt des selektierten Bereiches im IFrame platziert werden, was die folgenden Zeilen übernehmen:

doc.write('<div class="' + ele.attr("class") + '">' + ele.html() + '</div>'); doc.close();

Zum Schluss erhält das aktuelle IFrame den Focus und der Druck-Dialog beim Client wird aufgerufen, wobei der Timeout für den Opera-Browser sich von Vorteil erwies.

iframe.get(0).contentWindow.focus(); setTimeout(function() { iframe.get(0).contentWindow.print(); }, 10);

Disabled / Checked-Attribute mit jQuery setzen

weblog@drescher-hackel.de (René Drescher-Hackel) — Mon, 22 Sep 2008 22:26:02 GMT

Es gibt wohl kaum etwas, was sich mit jQuery nicht umsetzen läßt. So las ich die Tage, dass immer wieder Anfragen über eine große Suchmaschine gestellt wurden, wo nach einer Lösung gesucht wurde, wie man das disabled bzw. checked Attribute mit jQuery setzt.

Beide Attribute sind eigentlich ja mit einem boolschen Wert behaftet - entweder eine Element ist disabled oder nicht, es gibt also nur ein ja oder nein bzw. ein true oder false. Dem wird jQuery in einer Implementierung auch gerecht.

Für die folgenden HTML-Elemente

würde die jQuery-Umsetzung folgendermaßen aussehen:

$("#webInput").attr("disabled", true); $("#webButton").attr("disabled", true); $("#webCheckbox").attr("checked", true);

Folgt man der jQuery-Dokumentation, so kann aber auch folgende Lösung gesetzt werden:

$("#webInput").attr("disabled", "disabled"); $("#webButton").attr("disabled", "disabled"); $("#webCheckbox").attr("checked", "checked");

Möchte man den Attributwert jedoch genau umkehren, so bliebe bei der letztgenannten Lösung nur removeAttr, im erstgenannten Fall der Attributewert false zu setzen.

jQuery-Ansatz für transparente PNG Grafiken im Internet Explorer 6

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 13 Jul 2008 19:30:55 GMT

Wenn man PNG-Grafiken im Internet einsetzt, dann kommt man insbesondere beim Internet Explorer 6 an einem Problem an, nämlich dass dieser Browser die Transparenz der PNG-Grafiken nicht richtig darstellen kann.
Zur Lösung dieses Problems gibt es im Netz schon diverse Lösungen, wobei mir diese hier am meisten zusagt. Leider berücksichtigt diese Lösung nicht alle Attribute des Bildelementes und auch nicht mögliche Events.
Zu guter Letzt bleibt der Ansatz, den jQuery verfolgt hier unberücksichtigt. Der folgende Codeausschnitt nimmt sich diesem Problem an:

<script type="text/javascript">
$(document).ready(function(e){
                        $("img[src$='png']").each(function(e){
                        if(!$.browser.msie){
                            return;
                        }else if(parseInt($.browser.version) != 6){
                            return;
                        }
                        var div = $("<div />");
                        for(var n in this.attributes){
                            if(this[n] != "" && this[n] != null){
                                if(n.substr(0,2)=="on"){
                      div.bind(n.substr(2), this[n]);
                                }else if(n != "src"){
                    div.attr(n, this[n]);
                                }
                            }
                        }
                        div.attr("style", this.style.cssText);
                        div.css({
                            width   : this.width + "px",

height : this.height + "px",

filter : "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "', sizingMethod='scale')"
});

                        if(this.align == "left"){ div.css("float", "left"); }
                        if(this.align == "right"){ div.css("float", "right"); }
                        if(this.parentNode.href){ div.css("cursor", "hand"); }
                        this.parentNode.replaceChild( div[0], this );
                        });

                    });
</script>

Das ganze kann man natürlich als jQuery - Erweiterung implementieren, so dass der Code sich dann ändert in:

<script type="text/javascript">
    jQuery.fn.setPNGTransparenz4IE6 = function(){
        return this.each(function(e){
                if(!$.browser.msie){
                    return this;
                }else if(parseInt($.browser.version) != 6){
                    return this;
                }
                var div = $("<div />");
                for(var n in this.attributes){
                    if(this[n] != "" && this[n] != null){
                        if(n.substr(0,2)=="on"){
                            div.bind(n.substr(2), this[n]);
                        }else if(n != "src"){
                            div.attr(n, this[n]);
                        }
                    }
                }
                div.attr("style", this.style.cssText);
                div.css({
                    width  : this.width + "px",
                    height  : this.height + "px",
                    filter : "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "', sizingMethod='scale')"
                });
                if(this.align == "left"){ div.css("float", "left"); }
                if(this.align == "right"){ div.css("float", "right"); }
                if(this.parentNode.href){ div.css("cursor", "hand"); }
                this.parentNode.replaceChild( div[0], this );
            });
    }
$(document).ready(function(e){
    $("img[src$='png']").setPNGTransparenz4IE6();
});
</script>

Es hat sich nicht viel geändert am Code - die Auswahlabfrage auf alle Bilder die in der Dateierweiterung auf *.png enden findet jetzt außerhalb statt.
Auf diese Auswahl wird dann die Erweiterungsmethode setPNGTransparenz4IE6 aufgerufen.

Eventsource bei serverseitiger Eventregistrierung

weblog@drescher-hackel.de (René Drescher-Hackel) — Thu, 10 Apr 2008 22:59:38 GMT

Wenn man zB. an einem HtmlTable-Objekt serverseitig das onclick-Attribute setzt, so hat man wieder clientseitig das Problem, dass bei manchen Browsern der Eventparameter null bzw undefined ist. Eine Lösung könnte darin bestehen, dass man bei der serverseitigen Festlegung des Attributes das Objekt this mit an die Clientmehtode übergibt.

Das folgende Beispiel setzt ein onclick-Attribut auf ein HTML-Tabelle-Objekt.

ASPX Seite:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="LoadUserControl.aspx.cs" Inherits="M2Office.Web.TestSeiten.LoadUserControl" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>EventTest</title>
</head>
<body>
<form id="form1" runat="server">
<asp:RadioButtonList ID="RadioButtonList1" runat="server">
<asp:ListItem Text="Test1" Value="test1" />
<asp:ListItem Text="Test2" Value="test2" />
<asp:ListItem Text="Test3" Value="test3" />
</asp:RadioButtonList>
<asp:Table ID="Table1" runat="server">
<asp:TableRow ID="TableRow1" runat="server" TableSection="TableBody">
<asp:TableCell ID="TableCell1" runat="server" Text="Test1 0" />
<asp:TableCell ID="TableCell2" runat="server" Text="Test2 0" />
<asp:TableCell ID="TableCell3" runat="server" Text="Test3 0" />
</asp:TableRow>
<asp:TableRow ID="TableRow2" runat="server" TableSection="TableBody">
<asp:TableCell ID="TableCell4" runat="server" Text="Test1 1" />
<asp:TableCell ID="TableCell5" runat="server">
<asp:TextBox ID="TextBox1" runat="server" Text="Text in Textbox" />
</asp:TableCell> <asp:TableCell ID="TableCell6" runat="server" Text="Test3 1" />
</asp:TableRow>
<asp:TableRow ID="TableRow3" runat="server" TableSection="TableBody">
<asp:TableCell ID="TableCell7" runat="server" Text="Test1 2" />
<asp:TableCell ID="TableCell8" runat="server" Text="Test2 2" />
<asp:TableCell ID="TableCell9" runat="server" Text="Test3 2" />
</asp:TableRow>
</asp:Table>
</form>
</body>
</html>

CodeBehinde:

using System; namespace M2Office.Web.TestSeiten {
   public partial class LoadUserControl : System.Web.UI.Page {
      protected void Page_Load(object sender, EventArgs e) {
         RadioButtonList1.Attributes.Add("onclick", "MyClick(this)");
         Table1.Attributes.Add("onclick", "MyClick(this)");
      }
   }
}

Javascript:

Strings richtig formatieren

weblog@drescher-hackel.de (René Drescher-Hackel) — Tue, 15 Jan 2008 23:05:10 GMT

Immer wieder hilfreich - Alexander Zeitler hat in seinem Weblog eine Übersicht erstellt, wie man Strings richtig formatiert, wenn man bestimmte Anzeigeformen haben möchte.

Nach Alex's Weblog-Umzug war der Link kurzzeitig verschwunden.

Aber er ha sich ja wieder angefunden - Danke Alex!

ClientID vom ServerControl automatisiert verfügbar machen

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 22 Jul 2007 19:04:54 GMT

Im Rahmen der Webentwicklung steht man immer wieder vor dem Problem, die richtige ClientID nach dem Rendern des HTML zu ermitteln. Der eine (aber unschönste Weg!) ist, über die Quellcodeansicht die zahlreichen ClientIDs zu ermitteln und dann zum Beispiel hartcodiert im Javascript einzufügen.
Ein weiterer Weg ist über die Inlinecodeanweisung <% = ServerControlID.ClientID %> den Wert zu holen. Problemiliatisch ist dieses Vorgehen aber für den Fall, wenn man über eine externe Scriptdatei im Code die Information benötigt. Hier bekommt man dann solche Auskünfte:

Einen anderen Weg kann man gehen, wenn man auf JSON zurückgreift. Hier erlangt man fast vollständige Flexibilität über seine Clientobjekte.
Zunächst habe ich die Webseite nach allen Controls, die das ID-Attribute gesetzt haben, untersucht.

private void SetClientIDs( ControlCollection ctls) {
          foreach ( Control ctrl in ctls) {
             if (ctrl.HasControls())
                 SetClientIDs(ctrl.Controls);
             else
                 WriteControlIDtoSb(ctrl);
          }
}

In der Methode WriteControlIDtoSb(ctrl) erstelle ich dann den JSON-String:

private void WriteControlIDtoSb( Control ctrl) {
try {
if (ctrl.ID.ToString() != string.Empty) {
      sb.AppendFormat( "\"{0}\": {{" , ctrl.ID);
      sb.AppendFormat( "\"id\" : (\"{0}\"), ", ctrl.ClientID);
      sb.AppendFormat( "\"style\" : document.getElementById(\"{0}\").style, ", ctrl.ClientID);
      sb.AppendFormat("\"className\" : document.getElementById(\"{0}\").className, ", ctrl.ClientID);
   if (ctrl.GetType().Equals(typeof(DropDownList)) ||
      ctrl.GetType().Equals(typeof(HtmlSelect))) {
   if (ctrl.GetType().Equals(typeof(DropDownList)) && ((DropDownList)ctrl).Items.Count > 0) {
      sb.Append("\"Items\" : [ ");
   for (int i = 0; i < ((DropDownList)ctrl).Items.Count; i++) {
      sb.Append("{");
      sb.AppendFormat("\"value\" : document.getElementById(\"{0}\").options[{1}].value, ", ctrl.ClientID, i);
      sb.AppendFormat("\"text\" : document.getElementById(\"{0}\").options[{1}].text, ", ctrl.ClientID, i);
      sb.AppendFormat("\"selected\" : document.getElementById(\"{0}\").options[{1}].selected }}", ctrl.ClientID, i);
         if (i < ((DropDownList)ctrl).Items.Count - 1)
            sb.Append(", ");
   }
   sb.Append("] , ");
}
if (ctrl.GetType().Equals(typeof(HtmlSelect)) && ((HtmlSelect)ctrl).Items.Count > 0) {
   sb.Append("\"Items\" : [ ");
   for (int i = 0; i < ((HtmlSelect)ctrl).Items.Count; i++) {
      sb.Append("{");
      sb.AppendFormat("\"value\" : document.getElementById(\"{0}\").options[{1}].value, ", ctrl.ClientID, i);
      sb.AppendFormat("\"text\" : document.getElementById(\"{0}\").options[{1}].text, ", ctrl.ClientID, i);
      sb.AppendFormat("\"selected\" : document.getElementById(\"{0}\").options[{1}].selected }}", ctrl.ClientID, i);
         if (i < ((HtmlSelect)ctrl).Items.Count - 1)
            sb.Append(", ");
   }
   sb.Append("] , ");
}
   sb.AppendFormat("\"selectedText\" : document.getElementById(\"{0}\").options[document.getElementById(\"{0}\").selectedIndex].text,", ctrl.ClientID);
   sb.AppendFormat("\"selectedValue\" : document.getElementById(\"{0}\").options[document.getElementById(\"{0}\").selectedIndex].value,", ctrl.ClientID);
   }
   else {
      sb.AppendFormat("\"value\" : document.getElementById(\"{0}\").value, ", ctrl.ClientID);
   }
   sb.AppendFormat("\"onchange\" : document.getElementById(\"{0}\").onchange, ", ctrl.ClientID);
   sb.AppendFormat("\"onclick\" : document.getElementById(\"{0}\").onclick ", ctrl.ClientID);
   sb.Append("},");
}
}
catch { }
}

Hierbei habe ich den JSON-String so aufbereitet, dass ich nur bestimmte Eigenschaften im direkten Zugriff habe. Die Methode ist dabei beliebig erweiterbar und soll hier nur einen möglichen Ansatz wiedergeben.
Zum Schluss muss das ganze noch zum Client transportiert werden:

ClientScript.RegisterStartupScript(this.Page.GetType(), "ClientObjekte", string.Format("<script type='text/javascript' >\r\n var ClientObjekt = new Object(); \r\n eval('ClientObjekt = {{{0}}}}}');\r\n</script>", sb.ToString().Substring(0, sb.ToString().Length - 2)));

Auf der Clientseite kann ich dann auf meine Serversteuerelemente direkt zugreifen:

ClientObjekt.UCTextBox1.value - gibt den Text der TextBox "UCTextBox1" zurück.
ClientObjekt.dropdownControl.selectedText - gibt den ausgewählten Text der DropDownListe "dropdownControl" zurück.
ClientObjekt.dropdownControl.Items[0].text - gibt den Text des ersten Elements der DropDownListe "dropdownControl" zurück.

Der Debugger zeigt einen schönen Gesamtüberblick:

Update: Peter Bucher zeigt in seinem Weblog, wie das ganze sich noch umsetzen läst.

UniCode per Javascript ersetzen

weblog@drescher-hackel.de (René Drescher-Hackel) — Sun, 28 Jan 2007 23:02:56 GMT

Im Rahmen meiner aktuellen Projektarbeit war wieder einmal auf der Suche nach einer Lösung für folgendes Problem:

Ich habe mir ein CustomControl geschrieben, das ein GridView lädt und hier dann entsprechend der übergebenen Datenquelle den entsprechenden Text an eine Textbox im Control übergibt.
Jetzt kommt es im deutsche Sprachraum immer wieder vor, daß "Sonderzeichen" wie ü, ä, ö usw. verwendet werden. (Vielleicht kommt ja noch die Reform der Reform und diese Zeichen werden im Wege der Globalisierung aus dem Schriftzeichensatz der deutschsprachigen Regionen gestrichen)

Wie man sehen kann, zeigt das GridView das "ü" noch richtig an. Der gerenderte HTML-Code stellt das "ü" allerdings als Unicode das - also "ü". Im Ergebnis wird die so auch an die Textbox übergeben:

Da mir ad hoc erst einmal keine Lösung für dieses Problem einfiel, kam mir der Gedanke, das Ganze an der Stelle zu lösen, wo der Inhalt an die Textbox übergeben wird. Also mußte eine Javascriptlösung her.

Die Aufgabenstellung war dabei bekannt: Es gibt eine Zeichenfolge, die eine oder mehrere Zeichenfolgen beinhaltet, die dem Muster "&#Zahl;" entspricht.

Die Lösung ist dann ein prototype für String().

 String.prototype.fromDecCode = function(){
 var i = null;
 var _i = null;
 var temp = null;
 var str = this;
 myRegExp = new RegExp();
 i = str.indexOf('&#');
 if(i > -1){
 _i = str.indexOf(';');
 temp = str.substring(i+2, _i);
 myRegExp.compile(temp,'g');
 str = temp.replace(myRegExp, String.fromCharCode(temp));
 }
 return str;
 }

Damit war mein Problem gelöst.
Wie ich bei meiner Netzsuche feststellen mußte, hat sich in diversen Foren schon so manch anderer mit diesem Problem geplagt.

Update: 25.08.2007

Unicode - Codierungen für deutsche Umlaute

ä \u00c4
ä \u00e4
ö \u00d6
ö \u00f6
ü \u00dc
ü \u00fc
ß \u00df

Für die UniCode Convertierung ist die folgende Methode sehr hilfreich: String.prototype.fromUnicode