Nun gut, dachte ich mir, ist doch nicht so schlimm. Mach ich mir eben auch noch den Firefox 2 drauf. Geht ja ohne Probleme. Nur teilt der seine Add-ons offenbar mit dem 3er. Super… Also 3er deinstalliert. Und jetzt läßt sich der Firebug 1.0.5 gar nicht mehr installieren. Diese Erfahrung haben auch andere Leute gemacht. Mal suchen, obs auch irgendwo eine Lösung gibt…

Update: Mit einem neuen Profil geht die Installation. Mal schauen, ob Firebug so auch funktioniert. Um ein neues Profil anzulegen, den Browser schließen und in der Konsole mit “firefox-2 -ProfileManager” starten. Nachteil: Seitdem wird mir unter das Fenster ein XML-fehler gerendert: “</overlay>”. WTF???

Ob sich die Jungs um Jack S. einen Gefallen mit dem Lizenzwechsel einen Gefallen getan haben?

- org.directwebremoting.extend.MarshallException “No converter found for class“: Have a look in your DWR-Config. A def <dwr:convert type=”bean” class=”de.company.project.DWRBean*” /> will convert a bean with the name DWRBean, but not a bean DWRBean2. The * is misleading and does only work ‘properly’ in combination with a package: e.g. de.company.project.dwr.*”.

- Calls in JS to remote java-methods don’t return a value: If you call a remote method, you cannot simply assign the return value to a var. var x = remote.getX(); is wrong. The calls are done async, so you got to define callback-handler: remote.getX({callback: this.handleResponse.createDelegate(this, object), errorHandler: this.handleError.createDelegate(this, object)}); The createDelegate-method is ExtJs-specific and allows you to use ‘this’ in your callback. If you’re not working with extjs, just leave it out. (Hint for JS-Newbies: the callback-handler in this case only got one parameter, the returned object).

Für uns (kommerzielle) heißt das jetzt aber: Auf ExtJs kann man nicht mehr setzen. Ich bin mir noch nicht sicher, ob ich mich jetzt freuen soll, weil ich mich nicht mehr mit dem Scheiß rumschlagen muss, oder ob ich jetzt weinen soll, weil ich wieder eine neue API (noch unklar welche) lernen muss.

Nachtrag: Ich scheine nicht der Einzige zu sein, der sich nach Alternativen umschaut. Die DOJO-Seite scheint komplett überlaufen. Endlose Response-Time ..

vorher:

...
<div>
    <h1 id="header1">Hallo</h1>
</div>
...

nachher:

...
<div>
    <h1 id="header1">
        <a href="#" onclick="alert(this.tagName); return false">Hallo</a>
    </h1>
</div>
...

Dachte mir also, mit etwas DOM-Manipulation läßt sich der ganze Vorgang schön abwickeln und habe mir eine Funktion in dieser Art gebacken:

function tutNicht() {
    var heading = document.getElementById('header1');
    var headingText = document.createTextNode(heading.firstChild.nodeValue);

    var aElem = document.createElement('a');
    aElem.appendChild(headingText);

    var hrefAttrib = document.createAttribute("href");
    hrefAttrib.nodeValue = '#';

    var onclickAttrib = document.createAttribute("onclick");
    onclickAttrib.nodeValue = "alert(this.tagName); return false";

    aElem.setAttributeNode(onclickAttrib);
    aElem.setAttributeNode(hrefAttrib);

    heading.removeChild(heading.firstChild);
    heading.appendChild(aElem);
}

Jetzt wird es interessant. Der Internet Explorer (Version 6+7) führt zwar die Manipulationen am DOM aus (wovon ich mich mittels des IE DomInspectors überzeugte), wenn man dann aber auf den Link klickt wird das OnClick-Event nicht ausgelöst.

Habe länger im Trüben gestochert bis mir die Idee kam, den Link mal unschön über die Eigenschaft innerHTML der Überschrift zu erzeugen. Nun funktioniert die Sache plötzlich auch im IE und die Funktion alert() wir bei klicken aufgerufen:

function tut() {
    var heading = document.getElementById('header1');
    var text = heading.firstChild.nodeValue;
    heading.removeChild(heading.firstChild);

    heading.innerHTML = '<a href="#" onclick="alert(this.tagName); return false;">' + text + '</a>';
}

Ein äußerst interessantes Phänomen welches es noch zu ergründen gilt.