Firebug on Ubuntu Hardy Heron

Gestern habe ich fröhlich auf das neue Ubuntu upgedatet. Und siehe da: Der automatisch mitinstallierte Standardbrowser ist Firefox 3.0 Beta 5. Schönes Ding eigentlich. In der Ausführungsgeschwindigkeit von JS ein absoluter Renner! ABER: Firebug kann man zwar installieren (über Hinzufügen), nur stürzt das Ding bei mir reproduzierbar ab. Firebug ist also faktisch nicht verwendbar.

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???

OpenExt – (half)forking ExtJs

Für alle an der ExtJs-Problematik Interessierten und Verärgerten: Unter http://sourceforge.net/projects/openext/ werden Patches für die unter LGPL laufende ExtJs Version 2.0.2 entwickelt. Das Projekt ist kein wirklicher Fork, da immer noch rechtliche Unklarheiten -offenbar auch bezüglich den älteren Versionen- bestehen.

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

DWR-Newbie-Troubleshooting

– org.directwebremoting.extend.MarshallException caused by InstantiationException: It is logical, but I didn’t find the problem for hours: You’re dealing with beans here, so don’t forget a standard no-arg constructor!

org.directwebremoting.extend.MarshallExceptionNo 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).

ExtJs ist tot!

Die Javascript-Ajax-Bibliothek ExtJs ist in Version 2.1 erschienen. Warum schon wieder eine neue Version? Performance? Api-Verbesserung? Nix davon! Kommerz ist der Grund. Ab jetzt ist der Einsatz in kommerziellen Produkten nicht mehr ohne weiteres möglich. Knapp 300$ kostet eine kommerzielle Ein-Entwickler-Lizenz. open-Sourcisten bleiben verschönt. Für den Einsatz in OSS bleibt ExtJs kostenfrei.

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 .. 😉

Kann Internet Explorer mit setAttributeNode() kein Javascript-Event an DOM-Node binden?

Vorgestern trat ich mal wieder in eine Endlosschleife ein. Eigentlich wollte ich nur in einem XHTML-Dokument den Text innerhalb einer bestimmten Überschrift mit JavaScript zu einem Link umwandeln und diesen mit dem onclick-Attribut versehen. Quasi so:

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.