Problem

Beim Aufruf einer Webseite mit integriertem TinyMCE WYSIWYG Editor über eine UMTS-Verbindung, kommt es bei einigen UMTS Providern zu JavaScript-Fehlern und der Editor wird nicht angezeigt. Führt man danach aber ein “Deep-Refresh” der Seite (z.B. über Strg+F5 im Firefox) aus oder verwendet stattdessen eine DSL-Verbindung, wird der Editor vollständig geladen und korrekt dargestellt.

Ursache

Die meisten Mobilfunkprovider leiten alle Requests über einen transparenten Proxy, welcher diverse Transformationen an der Response vornimmt, um das Transfervolumen zu senken. Zu diesen Transformationen gehört neben der stärkeren Komprimierung von Bildern meist auch das Einbinden von externen Dateien (CSS und JavaScript) in das Hauptdokument. Dabei werden die script Tags so umgeschrieben, dass jeweils das src Attribut entfernt (oder auch umbenannt wird) und der Inhalt der referenzierten JavaScript Datei als Inline-Skript zwischen dem öffnenden und schließenden Tag eingefügt wird. Dadurch schlägt letztlich die Initialisierung des TinyMCE fehl, da in dieser Phase das src Attribut des script Tags, welches die tiny_mce.js (bzw. tiny_mce_src.js). Datei einbindet, ausgewertet wird. Der Pfad zu dieser Datei wird als Basis-URL für den Download weiterer TinyMCE Dokumente interpretiert (z.B. Skripte der konfigurierten Plugins oder Dateien des eingestellten Themes). Das Fehlen des Attributs führt zu den JavaScript-Fehlern.
Ein “Deep-Refresh” dagegen bewirkt, dass der Browser der Anfrage den Cache-Control Header mit dem Wert no-cache hinzufügt. Dieser Header wird auch von den Proxies berücksichtigt und das Dokument unverändert ausgeliefert, so dass der TinyMCE normal initialisiert werden kann.

Lösungsmöglichkeit

Eine Möglichkeit, um das Problem zu lösen, ist es, dem TinyMCE auf einem anderen Weg die Basis-URL zum Download der ergänzenden Skripte mitzuteilen, so dass nicht das src Attribut ausgewertet werden muss. Hierbei muss zwischen den Einbindungsmöglichkeiten des Editors unterschieden werden.

1. Direkte Einbindung

Bei dieser Methode wird der Editor einfach durch Hinzufügen eines script Tags, das auf das Hauptscript tiny_mce.js (bzw. die nicht-komprimierte Variante mit allen Leerzeichen, Zeilenumbrüchen und Kommentaren tiny_mce_src.js) verweist, integriert (vgl. TinyMCE:Installation). Das Setzen der Basis-URL kann durch Initialisieren der globalen Variable tinyMCEPreInit erfolgen. Das Hauptskript erwartet, dass die Variable ein Objekt mit den Eigenschaften suffix, base und query referenziert. Die Member haben dabei die folgende Bedeutung:

• suffix: entweder ein leerer String oder die Zeichenkette ‘_src’. Letztere sollte gesetzt werden, wenn die nicht-komprimierten Plugin-Skripte in das Dokument eingebunden werden sollen (z.B. zum Debuggen).
• base: der Wert der zu verwendenden Basis-URL, welche auf das Verzeichnis der TinyMCE Installation zeigt. Wurde z.B. das tiny_mce.js Skript mit der Adresse “http://server.de/javascript/tiny_mce/tiny_mce.js” eingebunden, dann ist die Basis-URL “http://server.de/javascript/tiny_mce”.
• query: erlaubt die Definition zusätzlicher Anfrageparameter, kann aber meist auf den leeren String gesetzt werden.

Ein vollständiges Beispiel, das die komprimierten Skripte verwendet sieht folgendermaßen aus:

<script type="text/javascript">
tinyMCEPreInit = {
    suffix: '',
    base: 'http://server.de/javascript/tiny_mce',
    query: ''
};
</script>
<script type="text/javascript" src="http://server.de/javascript/tiny_mce/tiny_mce.js" />

Hinweis: Die Variable findet sich in den aktuellen Versionen des TinyMCE (geprüft für 3.2.5, 3.2.7 und 3.3b1).

2. Enbindung über einen GZip Compressor

Bei dieser Variante wird nicht das Hauptskript in das Dokument eingebunden sondern ein Skript, das einen serverseitigen Compressor aufruft, der die benötigten TinyMCE JavaScript Dateien (Hauptskript, Plugins, Themes etc.) als ein GZip gepacktes JavaScript Dokument ausliefert (vgl. TinyMCE:Compressor). Das Skript des Compressors (tiny_mce_gzip.js) verwendet ebenfalls das src Attribut, um die Anfrage-URL für die serverseitige Komponente zu generieren. Um hier die Basis-URL zu setzen, muss die init Methode des in diesem Skript definierten tinyMCE_GZ Objekts ein wenig angepasst werden:

init : function(s, cb, sc) {
    var t = this, n, i, nl = document.getElementsByTagName('script');

    for (n in s)
        t.settings[n] = s[n];

    s = t.settings;
    if (s.baseUrl) {
        t.baseURL = s.baseUrl;
    } else {
        for (i=0; i<nl.length; i++) {
            n = nl[i];

            if (n.src && n.src.indexOf('tiny_mce') != -1)
                t.baseURL = n.src.substring(0, n.src.lastIndexOf('/'));
        }
    }
    if (!t.coreLoaded)
        t.loadScripts(1, s.themes, s.plugins, s.languages, cb, sc);
}

Die modifizierte Methode prüft, ob in den Settings eine baseUrl Eigenschaft vorhanden ist. Wird die Eigenschaft gefunden, wird sie als Basis-URL verwendet und die Auswertung des src Attributs übersprungen. Diese Eigenschaft kann dann einfach beim Initialisieren des Compressors gesetzt werden:

<script type="text/javascript">
tinyMCE_GZ.init({
    baseUrl: 'http://server.de/javascript/tiny_mce',
    ... normal init of compressor ...
});
</script>
<script type="text/javascript" src="http://server.de/javascript/tiny_mce/tiny_mce_gzip.js" />

Hinweis: Das Code-Beispiel für den Compressor wurde mit dem JSP Compressor in der Version 2.0.2 getestet, kann aber auch auf die .NET und PHP Compressoren übertragen werden, da der JavaScript Anteil gleich ist.

Dies ist eine Mitschrift zur Session “OpenSocial in the Enterprise” auf der Enterprise 2.0 Conference in San Francisco.

Im Panel vertreten waren vor allem Vertreter von Google, Atlassian, SocialText, IBM und eXo. OpenSocial ist eine Entwicklung die von Google nun als Open Source verfügbar gemacht worden ist. Die ursprüngliche Ausrichtung war auf das Umfeld von Social Networking ausgerichtet.

Die Technologie hat sich in den letzten beiden Jahren stark weiterentwickelt, liegt nun als Version 0.9 vor und geht nun auf die Version 1.0 zu. Inzwischen nutzen Dienste mit in Summe von mehr als 800 Mio. Nutzern die OpenSocial Technologie. Inzwischen wird viel über den Unternehmenseinsatz diskutiert. Google wird in Kürze ein “Enterprise OpenSocial Whitepaper” veröffentlichen.

Nachfolgend die Zusammenfassung der Diskussion im Panel.

Artikel vollständig lesen »

Mit dem Siegeszug von AJAX ist zugleich auch die Anzahl verfügbarer
Javascript-Frameworks explodiert.
Die Entwicklung der diversen Frameworks ist mittlerweile so weit fortgeschritten, daß es ein “bestes” Framework nicht mehr gibt.

Vielmehr setzen die “großen” unter den zahllosen Frameworks unterschiedliche Schwerpunkte und sind für verschiedene Anwendungsszenarien konzipiert. Dabei ist nicht jedes Framework für jeden Einsatzzweck gleichermaßen geeignet.

jQuery

Das zuletzt am schnellsten gewachsene Framework was die Anzahl der Nutzer angeht, ist jQuery. Mittlerweile ist es das meistverwendete Framework überhaupt. jQuery verfolgt dabei neben dem “schneller, einfacher” Grundkonzept aller Frameworks den Ansatz, auch Anwendern ohne tiefgehende Javascript-Kenntnisse die Entwicklung relativ komplexer JS-Applikationen zu ermöglichen.

Der Fokus von jQuery liegt auf DOM-Manipulationen, die mit jQuery so einfach zu realisieren sind wie mit kaum
eimem anderen Framework. Da alle jQuery-Funktionen das jQuery-Objekt zurückgeben, können die
Funktionen miteinander verkettet werden, wodurch die Lesbarkeit und Verständlichkeit des Codes
stark erhöht wird.

$("div.test").add("p.quote").addClass("blue").slideDown("slow");

jQuery zielt hauptsächlich auf die Standard-Anwendungsfälle, die in aktuellen Web-Frontends auftauchen:
Ausklappmenüs, Accordeonfunktionen, Tabs, Tooltips, Formularvalidierung, Drag&Drop, AJAX etc.

Diese Standard-Anwendungen sind in der Umsetzung so einfach wie möglich gehalten, die Lernkurve bei jQuery ist daher recht flach und es stellen sich schnell erste Erfolge ein. Die 2000 frei verfügbaren Plugins bieten vorgefertigte Lösungen für nahezu alle denkbaren Anwendungsfälle allerdings in unterschiedlicher Qualität.

Aufgrund des eigenen Namensraums kann jQuery parallel zu allen anderen Frameworks betrieben werden.
Was die Performance angeht ist jQuery spätestens seit Version 1.3, mit der die Sizzle Selektor-Engine eingeführt wurde, führend unter den JS-Frameworks.

Prototype

Prototype ist eines der ältesten Frameworks (seit 2005) und hat dementsprechend großen Einfluss
auf die nachfolgenden Generationen gehabt. (z.B. MooTools)
Die Popularität von Prototpe ist nach wie vor ungebrochen, u.a. wird es zusammen mit Ruby on Rails ausgeliefert.
Prototype erweitert Javascript um zahlreiche Funktionen und verfolgt einen objektorientierten Ansatz, der die Nachbildung von eigenen, instanziierbaren Klassen sowie Vererbung erlaubt. Ein eigenes AJAX-Objekt steht zur Verfügung, ebenso wie JSON-Unterstützung.

Die umfangreiche Bibliothek eignet sich mit ihrer breiten inhaltlichen Ausrichtung zeichnet sich durch eine qualitativ hochwertige Codebasis und eine hohe Flexibilität aus. Allerdings erkauft man sich diese Flexibilität auch mit einem relativ hohen Einarbeitungsaufwand, Frameworks wie JQuery machen es dem Einsteiger in diesem Punkt leichter. Die gute Dokumentation hilft allerdings in den meisten Fällen über die auftauchenden Hürden hinweg.

Prototype bringt von Hause aus keine Widgets und Funktionen für visuelle Effekte mit, diese können jedoch über die Erweiterung scriptaculous zusätzlich eingebunden werden. Zudem stehen in der Prototype Extension Library knapp 150 Erweiterungen und Widgets zur Verfügung.
Nachteile von Prototype sind die mäßige Performance insb. in den verschiedenen Versionen des IE, teilweise ist Prototype um den Faktor 6 langsamer als die Konkurrenz (JQuery).

Google Web Toolkit (GWT)

Das Google Web Toolkit (GWT) verfolgt einen gänzlich anderen Ansatz als die anderen Javascript-Frameworks.
Das GWT bietet eine Java-Bibliothek, die es ermöglicht, AJAX-Anwendungen in Java zu schreiben und
den Bytecode dann in Java-Script kompilieren zu lassen. Dadurch kann die komplette Client/Server-Entwicklung auf Java-Basis erfolgen. Die Web-Applikation (gleich ob mit oder ohne AJAX) wie eine Desktop-Applikation im Java-Umfeld erstellt, die Oberflächenprogrammierung ähnelt dabei Swing. Seit Version 1.5 wird auch Java 5 voll unterstützt.

Dieses Java-basierende Konzept unterscheidet das GWT fundamental von allen anderen Frameworks aus dem Bereich
und bietet eine Reihe von Vorteilen:

• es können alle bekannten Entwicklertools aus dem Java-Umfeld eingesetzt werden, incl. JUnit Tests und Debugger
• Fehlermeldungen zur Compilezeit
• es sind im Prinzip keine Javascript-Kenntnisse erforderlich
• Aktualisierung des GWT genügt, um sich aktuellen (Browser)-Entwicklungen anzupassen

Auch an weitere Merkmale aus dem Enterprise-Segment wurde gedacht: So ist eine einfache Internationalisierung über Property-Dateien möglich und zahlreiche vorgefertigte Widgets stehen einsatzbereit zur Verfügung.
Die asynchrone Kommunikation mit dem Server verläuft über Remote Procedure Calls und XML oder JSON.

Zum Testen steht ein Hosted Mode zur Verfügung, dieser führt den Java-Bytecode direkt aus und ermöglicht unmittelbares Testen, ohne den “Umweg” über Javascript. Der Web Mode ist dagegen für die Produktivumgebung gedacht und arbeitet mit dem generierten Javascript.

Auch Ansätze zur Barrierefreiheit sind vorhanden. So wird über History-API die volle Funktionsfähigkeit des zurück-Buttons des Browsers auch bei AJAX-Aufrufen sichergestellt, zudem wird eine reine Tastaturbenutzung und Schriftgrößeneinstellung ermöglicht.

Im die Performance zu steigern, erzeugt der Javascript-Compiler pro Browser und Sprache eine eigene Javascript-Datei. Dadurch werden geringe Dateigrößen ermöglicht. Außerdem werden Icons automatisch zu einem Einzelimage (ImageBundle) zusammengefasst, wodurch die Zahl der HTTP-Requests und damit die Ladezeit drastisch reduziert werden kann.

Für das GWT stehen zahlreiche Widgets und Extensions auch von Fremdanbietern zur Verfügung.

Google Dienste wie Google Maps werden können über die API nahtlos integriert werden, auch Google Gears wird unterstützt.
Die Klassen des GWT können bei Bedarf auch mit handgeschriebenen JavaScript innerhalb des Java-Quellcodes gemischt werden (JavaScript Native Interface (JSNI))

Aufgrund seiner Konzeption als Java-Bibliothek ist das GWT in erster Linie für umfangreiche Javascript-basierende Applikationen wie bspw. GMail gedacht. Als bloßes Hilfsmittel für DOM-Manipulationen ist es überdimensioniert und der Einarbeitungsaufwand ist zu hoch. Für Entwickler aus dem JAVA-Umfeld aber durchaus interessant, sofern die Projekte massiven Javascript-Einsatz erfordern und Java-Entwicklungswerkzeuge genutzt werden sollen.

An Silverlight und einem seiner meist gepriesenen Features, nämlich Deep Zoom, dürften mittlerweile die meisten Entwickler von Web-Anwendungen schon einmal vorbeigekommen sein.

Ein paar der prominenteren Beispiele: Obama Headlines, A Website Named Desire, Deep Zoom Obama, die Hard Rock Cafe Memorabilia Wall, DeepLOL, die Website des Renault Laguna Coupé, etc.

Die Vertigo Software Inc. wirbt sogar mit dem Claim “Zoom is the new click“.

Man muss kein Zauberkünstler sein, um selbst ein Deep Zoom Bild erstellen zu können.

Dazu lädt man sich einfach den Deep Zoom Composer herunter, mit dem man bequem ein Deep Zoom Image (.dzi) erzeugen kann. (Hilfe, inkl. bebilderter Anleitung)

Was vielleicht weniger bekannt ist:

Man kann die Deep Zoom Images auch schnell und einfach online erstellen lassen, mit dem Microsoft Live Labs Projekt “PhotoZoom“.

Ich habe dort mal eine Deep Zoom Version des Canaletto-Blicks erstellt.

Deep Zoom – Demo (Silverlight)

Aber es geht noch weiter! Für Umgebungen in denen Silverlight nicht verhanden oder nicht möglich ist, kann man die DZI-Bilder auch mittels der Seadragon Ajax Bibliothek anzeigen lassen.

Deep Zoom – Demo (Seadragon Ajax)

Viel Spaß beim Zoomen!

Mit Hilfe von Web Part Page Service Component – kurz WPSC – können recht einfach zusätzliche Funktionalitäten eingebunden werden. WPSC ist ein Satz von JavaScript-Funktionen erlaubt, dass z.B. Webparts untereinander, mit SharePoint und mit dem Benutzer interagieren.

Im Folgenden möchte ich anhand des Beispiels von Woody Windishman kurz im Ansatz zeigen, welche Möglichkeiten sich bieten.

Oft erwarten Benutzer von Webanwendungen die gleichen Features, die sie auch von Desktop-Anwendungen schon kennen. Ein in Desktopanwendungen sehr triviales und leicht zu implementierendes Beispiel – wie Aufruf einer kontextsensitiven Hilfe bie Druck auf F1 – gestaltet sich im Web schon schwieriger. Hier können WPSC eine Brücke schlagen.

Wie realisiert man das Ganze nun? Das Prinzip ist recht einfach und in zwei simplen Schritten erklärt:

1. Man erzeugt eine JavaScript-Funktion, die in einem neuen Fenster die Hilfe-HTML-Seite öffnet.
2. Man registriert diese Funktion für den gewünschten Event.

Soweit die Theorie – nun zur Praxis:

Gehen wir davon aus, dass bereits eine Hilfeseite existiert – im Beispiel die Seite AppHelp.aspx in der Wiki-Bibliothek HelpWiki. Weiterhin gehen wir davon aus, dass eine WebPart-Page existiert, für die Kontexthilfe angeboten werden soll.

Nun soll das JavaScript zum Aufruf der Hilfeseite integriert werden. Das geht recht einfach mit einem Content-Editor-Webpart durchgeführt werden. Aus diesem Grund öffnen wir die Seite im Design-Mode (“Site Actions” -> “Edit Page”) und fügen einen Content-Editor-Webpart hinzu. Unter “Modify Shared Web Part” muss nun der Source Editor geöffnet und folgendes JavaSript hinzugefügt werden:

Der Inhalt ist schnell erklärt: Im oberen Teil die Funktion “showMyHelpPage” öffnet die Hilfeseite in einem neuen Fenster und im unteren Teil wird mittels WPSC.RegisterForEvent die obige Funktion für das Ereignis registriert. “return false;” am Ende der JavaScript-Funktion unterbindet, dass sich die browsereigene Hilfe auch noch öffnet und der Anwender von Hilfeseiten erschlagen wird.

Nun wird wird das WebPart noch ausgeblendet mittels Chrome-Eigenschaft “None”. Die Dialoge und der Bearbeitungsmodus können nun wieder verlassen werden.

Drückt der Anwender nun auf der Webseite F1, so öffnet sich ein neues Browserfenster, in dem die Hilfetexte stehen.

Natürlich können diese Funktionen nicht nur in die Webpartseiten, sondern auch direkt in die Masterpage eingebettet werden – dann muss die JavaScript-Funktion zum Aufruf der Hilfeseite mit entsprechenden Parametern versehen und etwas mehr einer Logik gefüllt werden.

Ich denke  es wird deutlich, das man hier ein paar nette Funktionen an die Hand bekommt, mit denen man die User Experience verbessern kann.

Weitere Informationen zu WPSC finden sich im SharePoint-SDK oder in der MSDN.

Die Standard-MasterPage von SharePoint (default.master) wurde ohne Angabe eines DOCTYPE geschrieben. Dadurch fällt der IE beim Rendern in den Quirks Mode zurück. Entsprechend wurden SharePoint-eigene Funktionalitäten wie das Verschieben eines WebParts auf Grundlage des Quirks Mode geschrieben.

Wenn man sich nun aber an Standards halten, und einen DOCTYPE angeben möchte, bekommt man u.U. Probleme in SharePoint.

So bringt zum Beispiel des Einfügen der Angabe

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

einen Fehler beim Ausführen der JavaScript-Methode “MSOLayout_GetRealOffset” hervor, wenn sich der WebPart in einem relativ positionierten DIV befindet:

Message: Objekt erforderlich
Line: 1572
Char: 3
Code: 0
URI: http://SERVER/_layouts/1031/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D

Mögliche Lösungen für dieses Problem sind:

1. Anpassen der JavaScript-Methode

Dies sollte jedoch nicht direkt in der <12>\TEMPLATE\LAYOUTS\1033\IE55UP.JS geschehen, da es dort durch Updates überschrieben werden kann. Und spätestens beim Deployen auf einer Farm wird es umständlich.

Daher sollte man die Anpassung lieber in seiner Masterpage vornehmen. Dazu überschreibt man einfach die “fehlerhafte” Methode indem man nach SPWebPartManager folgenden Code einfügt:

<script language="javascript" type="text/javascript">
   1: 
   2:     function MSOLayout_GetRealOffset(StartingObject, OffsetType, EndParent)
   3:     {
   4:         var realValue=0;
   5:         if (!EndParent) EndParent=document.body;
   6:         for (var currentObject=StartingObject; currentObject && currentObject !=EndParent && currentObject != document.body; currentObject=currentObject.offsetParent)
   7:         {             var offset = eval('currentObject.offset'+OffsetType);
   8:             if (offset) realValue+=offset;
   9:         }
  10:         return realValue;
  11:     }
</script>

oder 2. Vermeiden von position:relative bei Containern für WebParts

Stattdessen kann man z.B. float verwenden. Dazu gibt es diverse MasterPage-Vorlagen.

oder 3. Entfernen der DOCTYPE-Angabe in der MasterPage

Das ist eine schnelle Lösung, aber kein optimales HTML. Eine Triple-A Conformance für “Premium”-Barrierefreiheit wird man dadurch nicht erreichen können. Andererseits: Die default.master wird ja auch so ausgeliefert…

Englischsprachige Quellen zu diesem Thema:

• Heather Solomon: “The DOCTYPE tag and SharePoint Master Pages“
• Tech MOSS Team: “CSS causes JavaScript error while moving Web Parts in edit mode“

Als netter ASP.Net Programmierer mutet man dem Anwender wegen eines Klicks in eine CheckBox (in diesem Fall als Item einer CheckBoxList) kein Postback/Reload der Seite zu. Nun hat man ja aber vielleicht doch den Wunsch, das eine oder andere beim Klick zu erledigen – clientseitig per Javascript. Wenn möglich, will man den einzelnen CheckBoxList Items noch ein paar Attribute mitgeben, die in der Javascript-Funktion ausgewertet werden können und im Idealfall weiß die Javascript-Funktion auch gleich, welcher Item geklickt wurde. Das sollte eigentlich kein Problem sein – denkt man.

Also versucht man es erstmal ganz einfach mit folgendem Codeschnipsel im C# CodeBehind der Seite:

-> keine Reaktion

Das gleiche noch einmal mit “onclick” anstelle “onchange” -> selbes Ergebnis

Nun hilft alles nichts – man fängt an nachzudenken… Ein Blick in den Seitenquellcode ist ziemlich aufschlussreich: Die CheckBoxList Items haben einen <span> um den eigentlichen <input>-Tag des Items stehen – und in diesem landen unsere Attribute:

So funktioniert das also leider nicht. Ein kurzes Googlen zeigt nicht nur, dass andere das Problem auch schon hatten, sondern auch eine Lösung: Das “onclick” darf nicht an die einzelnen Items, sondern muss an die CheckBoxList gebunden werden:

Welcher Item geklickt wurde, kann man nun leider nicht mehr einfach an die Javascript-Funktion übergeben. Dies muss man über eine for-Schleife herausfinden. Die Attribute für die einzelnen Items können aber mit einem kleinen Trick trotzdem in der Javascript-Funktion abgefragt werden: Man legt sich zusätzlich zum Array mit den CheckBoxList Items (<input>-Tags) noch ein Array für die Attribute (<span>-Tags) an, das natürlich die gleiche Länge hat und über den gleichen Index abgefragt werden kann.

Alles in allem sieht die Javascript-Funktion in der Seite dann so aus:

function CheckboxChanged()
{
var checkBoxList = document.getElementById(‘<%= SampleCheckBoxList.ClientID %>’);
//Array für die CheckBoxList Items
var checkboxes = checkBoxList.getElementsByTagName(‘input’);
//Array für die Attribute der CheckBoxList Items
var checkboxAttributes = checkBoxList.getElementsByTagName(’span’);
for (var i=0; i<checkboxes.length;i++)
{
alert(checkboxes[i].checked);
alert(checkboxAttributes[i].code);
alert(checkboxAttributes[i].text);
}
}

Und der C# CodeBehind für das Hinzufügen des “onclick” und der Attribute so:

//set attributes for the items of SampleCheckBoxList (reqired for javascript function)
foreach (ListItem item in SampleCheckBoxList.Items)
{
item.Attributes.Add(“code”, item.Value);
item.Attributes.Add(“text”, item.Text);
}
//set the javascript function to be called at a checkbox item click
SampleCheckBoxList.Attributes.Add(“onclick”, “CheckboxChanged()”);

Das sollte wirklich kein Problem sein…

Manchmal hat man ein Problem, und wenn man es dann gelöst hat, ist die Lösung so einfach, dass man es fast nicht glauben mag. So ging es mir mit folgender Aufgabe:

Gegeben ist ein String, der ein XML Document repräsentiert:

<books>
<book author=”Meier”>Lexikon der Meierei</book>
<book author=”Muster”>Patterns in der Schneiderstube</book>
</books>

Diesen String möchte man (möglichst browserunabhängig, wenigstens soll es aber für Internet Explorer und Firefox funktionieren) per Javascript in ein XML DOM Object parsen, um dieses dann, wie auch immer, weiter zu verwenden. Und das geht ganz einfach so:

function MyParseXml(xmlString)
{
var xmlDoc;
//for IE
if (window.ActiveXObject)
{
xmlDoc = new ActiveXObject(“Microsoft.XMLDOM”);
xmlDoc.async = “false”;
xmlDoc.loadXML(xmlString);
}
//for Mozilla, Firefox, Opera, etc.
else if (document.implementation && document.implementation.createDocument)
{
var parser = new DOMParser();
xmlDoc = parser.parseFromString(xmlString,”text/xml”);
}
var x=xmlDoc.getElementsByTagName(‘book’); //oder wasauchimmer
}

Fertig!