Christians Blog

Zu meinem ersten Firefox-Add-on namens azid gesellt sich nun ein weiteres: defyFormValidation.

Es deaktiviert die mit HTML5 eingeführte Browser-seitige Formularvalidierung. Je nach Einstellung geschieht dies entweder per Klick auf eine Symbolleistenschaltfläche für die aktuelle Seite oder automatisch für jede Seite. Das Add-on richtet sich in erster Linie an Web-Entwickler, die sowohl die serverseitige Validierung der Anwendung (die neben der clientseitigen, welche lediglich eine Maßnahme zur Steigerung der Nutzerfreundlichkeit ist, immer vorhanden sein sollte) als auch alternative clientseitige (z. B. JavaScript-basierte) Methoden zur Formularvalidierung testen möchten.

Natürlich könnte man, da man als Entwickler Zugriff auf den Quellcode der Formulare hat, die Validierung testweise selbst deaktivieren, aber es ist angenehmer, dies nicht manuell tun zu müssen. Außerdem lässt sie sich auf diesem Weg auch für Formulare auf fremden Webseiten deaktivieren, um diese zu testen. 😉

Weitere Informationen gibt es auf der Projektseite zu defyFormValidation.

Die ursprüngliche Version 0.1 hatte ich am 13.05. im Add-on-Katalog eingetragen und Version 0.2 zwei Tage später ergänzt. Ich wollte mit dem ankündigenden Blog-Beitrag eigentlich warten, bis das Add-on geprüft und freigegeben wurde. Aufgrund der Flut neuer Add-ons für Firefox 4 wird das von Verantwortlichen bei Mozilla durchgeführte Review allerdings noch einige Zeit dauern, wobei derzeit von etwa zwei Monaten ausgegangen wird.

Nachtrag 02.07.2011 09:47:
Wider Erwarten wurde das Add-on nun doch schon letzte Nacht, etwa zweieinhalb Wochen seit Veröffentlichung, freigegeben.

Nachdem die Aktion am 7. Januar dieses Jahres endete (siehe Aktualisierung vieler Firefox-Add-ons – Für Gratis-T-Shirt?), lag nun endlich das T-Shirt im Briefkasten. Auf dem Versandbeleg ist ein Wert von fünf US-Dollar angegeben. Es macht einen guten Eindruck, passt und sieht aus wie im Beitrag zum Firefox-T-Shirt im mozillaZine-Forum abgebildet.

In den letzten Tagen sind auffällig viele Firefox-Add-ons aktualisiert worden, um sie mit Version 4 kompatibel zu machen. So z. B. Firebug und Web Developer. Da sind die Entwickler wohl scharf auf kostenlose T-Shirts mit Firefox-4-Logo. Ich bin ja mal gespannt, wie das aussehen wird, denn eigentlich sollte ich auch eins erhalten. 😀

Nicht ganz acht Monate nach der Veröffentlichung meines ersten Firefox-Add-ons azid in Mozillas Add-on-Katalog, mit bisher vier Aktualisierungen, wurde es laut der in den Katalog integrierten Statistik bis heute knapp über 5500-mal heruntergeladen und hat derzeit fast 800 tägliche Benutzer. Mittlerweile ist es sogar in sieben Sprachen verfügbar. Das ist sicherlich nicht weltbewegend, aber für ein kleines Projekt, das aus Eigenbedarf und Experimentierfreude entstand, finde ich das gar nicht schlecht.

Ich stand gerade vor dem Problem, für mein Firefox-Add-on azid die kompatiblen Firefox-Versionen anzugeben. Aufgrund eines Fehlers in einigen Firefox-Versionen müsste ich nun theoretisch zwei Bereiche von Versionsnummern festlegen, von 2.0 bis 3.6.* und von 4.0b2 bis 4.0b3pre, da in den Versionen 3.7a4 (erste verfügbare inkompatible) und 4.0b1 (letzte inkompatible) sowie wahrscheinlich (ungetestet) den Versionen dazwischen das Add-on nicht funktioniert. Praktisch ist leider nur die Angabe genau eines Bereichs unterstützter Versionen einer Anwendung (z. B. Firefox) möglich, sodass weder

<em:targetApplication>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
    <em:minVersion>2.0</em:minVersion>
    <em:maxVersion>3.6.*</em:maxVersion>
  </Description>
</em:targetApplication>
<em:targetApplication>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
    <em:minVersion>4.0b2</em:minVersion>
    <em:maxVersion>4.0b3pre</em:maxVersion>
  </Description>
</em:targetApplication>

noch

<em:targetApplication>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
    <em:minVersion>2.0</em:minVersion>
    <em:maxVersion>3.6.*</em:maxVersion>
  </Description>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
    <em:minVersion>4.0b2</em:minVersion>
    <em:maxVersion>4.0b3pre</em:maxVersion>
  </Description>
</em:targetApplication>

eine Lösung sind. Eine Beschreibung dieses Konstrukts gibt es bei Mozilla. Somit bin ich gezwungen, einen Bereich wie

<em:targetApplication>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
    <em:minVersion>2.0</em:minVersion>
    <em:maxVersion>4.0b3pre</em:maxVersion>
  </Description>
</em:targetApplication>

anzugeben, obwohl er eigentlich falsch ist. Zumindest habe ich der Projektseite von azid Informationen zu (in)kompatiblen Versionen hinzugefügt.

Die Festlegung mehrerer disjunkter Versionsmengen wäre wünschenswert, um solche dem Add-on-Entwickler bekannten Inkompatibilitäten den potenziellen Nutzern mitzuteilen und auch in den Prozess der Add-on-Suche und -Installation einfließen zu lassen.

Ich habe mein altes Java-Projekt jAZIC nun in einer Neuauflage als Firefox-Add-on umgesetzt. Damit lassen sich die von Amazon mit der Zoom-Funktion bereitgestellten, hochaufgelösten Produktbilder noch angenehmer speichern. Mehr dazu auf der Projektseite zu azid.

Damit wurde ich gerade im aktuellen Firefox 3.6 konfrontiert. Soweit ich mich erinnern kann, wurde man in früheren Firefox-Versionen über den Namen der schuldigen Datei sowie die Zeilennummer informiert und man hatte noch die Möglichkeit, die Ausführung des Skriptes abzubrechen oder auf dessen Ende zu warten. Ich hake das mal als Usability-Verbesserung ab.