Die Zusammenstellung der Bibliotheken kommt durch Abstimmung aus der Community zustande. Es besteht eine ständige Diskussion direkt auf der Webseite, wo Vorschläge für potentielle Neuzugänge gesammelt werden und das Votum per Mausklick stattfindet (Authentifizierung erfolgt mit einer Emailadresse oder per Facebook/Google Account). Das Hosting der aktuellen Auswahl übernimmt freundlicherweise Cloudflare, ein Unternehmen aus San Francisco, Kalifornien.

- "required" Felder
- Emails
- Slider
- Placeholder
- Numerische Eingaben

Die neuen HTML5 Eingabefelder sollen die Workarounds ersetzen, die in den vergangenen Jahren vornehmlich mit JavaScript, z.B. mit JQuery UI umgesetzt worden sind. Zukünftig wird die Syntax kürzer und einfacher, es bedarf keiner JS-Bibliotheken mehr, die Bandbreite fressen, dafür unterwirft man sich aber auch den Optik der Elemente, wie sie der Browserhersteller definiert. Ein Datepicker sieht in Zukunft so aus:

<input type="date" min="2010-04-18" max="2017-04-18" value="2012-04-18"/>

Simpel, oder? Wer mit den neuen Elemente herumspielen möchte oder einfach prüfen will, inwieweit der eigene Browser schon kann, was HTML5 bezüglich Eingabefeldern verspricht, dem empfehlen wir obigen Link zu HTML5rocks.

Man nehme eine HTML Textarea, spezifiziere in zwei Zeilen Code, wie der Editor aussehen soll und welche Programmiersprache darin eingetippt wird, und schon verwandelt CodeMirror das mehrzeilige Textfeld in einen ansehnlichen Editor. Viel Funktionalität ist nicht enthalten, immerhin ist CodeMirror nicht als WYSIWYG Editor gedacht. Dennoch ist der Editor nicht zu unterschätzen, wie zum Beispiel diese HTML Demo zeigt. Oder der FullScreen-Modus.

Nicht von dem Affen mit dem roten Hintern auf CodeMirror.net ablenken lassen!

CodeMirror unterstützt mehr als 40 Sprachen und Dialekte. Entsprechend wuchtig kommt der Download daher - glücklicherweise kann man sich ein maßgeschneiderten Build selbst zusammenklicken. Für PHP liegt man dann bei etwa 70kb, für MySQL sind es weniger als 60. Das Gros macht jecoch immer der Kern der Library aus.

Um Codemirror zu verwenden, muss wie üblich die JavaScript Datei in die eigene Seite eingebunden werden. Damit das Syntax Highlighting auch sichtbar wird, bedarf es zusätzlich eines Cascading Stylesheets.

<!-- wir befinden uns im Header, das JS kann wahlweise auch vor das /body Tag -->
<link rel="stylesheet" href="codemirror.css">
<script src="codemirror.js"></script>

Die Initialisierung erfolgt über einen weiteren JavaScript Aufruf

var editor = CodeMirror.fromTextArea(document.getElementById("code"), {
        lineNumbers: true,
        mode: "application/x-httpd-php"
      });

Dieses Kommando greift auf die Textarea mit der ID code zu, der Modus ist PHP. Bei der Initialisierung wird das eigentliche textarea Element ausgeblendet und durch eine Struktur aus div Elementen ersetzt. Eine mittelmäßig ausführliche Dokumentation findet sich im Manual der Bibliothek.

P.S.: Das Icon stammt aus dem Flavours Icon Set von Oliver Twardowski.

1. Ein SELECT absetzen, das genau nach der Kombination von Schlüsselattributen sucht, die man einfügen möchte. Liefert das SELECT einen Datensatz zurück, dann macht man ein UPDATE, sonst ein INSERT. Oder
2. Gleich ein INSERT absetzen und prüfen, ob ein ERROR 1062 (23000): Duplicate entry... zurückkommt. Wenn ja, dann ein UPDATE hinterherschieben.

Beides erzeugt wesentlich zu viel Aufwand. Nehmen wir beispielsweise folgende MySQL-Tabelle

CREATE TABLE upsert (
id INT(11) NOT NULL,
updated_on TIMESTAMP NOT NULL,
value VARCHAR(100) NOT NULL,
PRIMARY KEY (id));

Die Tabelle ist sehr einfach strukturiert: id dient als Primärschlüssel (ohne AUTO INCREMENT), updated_on hält den Zeitpunkt der letzten Änderung fest und value speichert irgendeinen Wert. Mit

INSERT INTO upsert (id, updated_on, value) VALUES (1, CURRENT_TIMESTAMP, 'abc');

wird ein erster Datensatz eingefügt. Wird dasselbe Statement noch einmal abgesetzt, kommt es zum oben beschriebenen Fehler 1062. Ist der Tabelleninhalt beim Einfügen nicht bekannt, hilft uns das UPSERT weiter:

INSERT INTO upsert (id, updated_on, value) VALUES (1, CURRENT_TIMESTAMP, 'abc')
ON DUPLICATE KEY UPDATE updated_on = CURRENT_TIMESTAMP, value = 'abc';

Die Schlüsselattribute müssen im zweiten Teil des Befehls natürlich nicht mit angegeben werden, denn bei dem alternativen UPDATE verändern sie sich naturgemäß nicht. Anstatt im UPDATE dieselben Parameter wie im INSERT zu nutzen, kann man auch andere Werte zuweisen.
Noch einfacher ist natürlich, wenn man die Parameter (CURRENT_TIMESTAMP und 'abc') nicht zweimal in seinen Befehl einbauen muss. Das hilft besonders bei der Verwendung von Prepared Statements. Diesen Komfort erreicht man durch die Verwendung des VALUES() innerhalb des UPDATE-Teils. Damit hat man Zugriff auf die Werte, die man im vorderen Teil des Befehls festgelegt hat.

INSERT INTO upsert (id, updated_on, value) VALUES (1, CURRENT_TIMESTAMP, 'abc')
ON DUPLICATE KEY UPDATE updated_on = VALUES(updated_on), value = VALUES(value);

2 ROWS AFFECTED???

Bei genauerer Betrachtung fällt noch eine Eigenheit des UPSERT auf. Auch wenn sich nur ein Datensatz in der Tabelle befindet, vermeldet MySQL die erfolgreiche Ausführung des UPSERT mit

Query OK, 2 rows affected (0.00 sec)

Das ist kein Fehler, sondern ein gewünschtes und dokumentiertes Verhalten. Wird bei einem UPSERT eine Zeile eingefügt, meldet MySQL 1 row affected, muss stattdessen eine Aktualisierung vorgenommen werden, sind es eben 2.

MariaDB, der MySQL Fork von Monty Widenius, ist zwar immer noch so nah am Original, damit auch Handlersocket darin läuft, bietet allerdings eigene Funktionen an, um das gleiche ohne Plugin zu erreichen: HANDLER Kommandos. Darunter sind alternative SQL Kommandos zu SELECTs zu verstehen, die dem Server sagen: Ich will Datensatz xy im Index abc suchen. Der explizite Verweis auf den Index-Eintrag beschleunigt die Abfrage natürlich.

Index Scans
Im Folgenden nutzen wir die Beispieldatenbank employees-db aus dem Launchpad. Anstatt

SELECT * FROM employees WHERE emp_no=100000;

steht dann

HANDLER employees OPEN;
HANDLER employees READ unique_idx=(100000);
HANDLER employees CLOSE;

Statt einem Statement braucht ein Handler zusätzliche OPEN und CLOSE Anweisungen. Der Vorteil des Handlers wird hieraus nicht sichtbar. Das Ergebnis ist nämlich das gleiche wie im obigen SELECT: Es werden alle Spalten des Datensatzes zurückgegeben, in dem die ID gleich 100000 ist. Allerdings erlaubt der Handler, den Index zu durchwandern:

HANDLER employees OPEN;
HANDLER employees READ unique_idx=(100000);
HANDLER employees READ unique_idx NEXT;
HANDLER employees READ unique_idx PREV;
HANDLER employees READ unique_idx LAST;
HANDLER employees CLOSE;

Es lassen sich also mehrere Abfragen innerhalb des Handlers abfackeln. Vorsicht ist allerdings geboten, wenn es um den Index geht. Im obigen Beispiel wird unique_idx verwendet, der in der employees-db nicht von Vornherein angelegt ist. Wir hatten Schwierigkeiten, den Handler mit dem Primary Key zu verwenden, der auch PRIMARY heißt. Hier scheint es einen Konlikt mit dem reservierten Wort zu geben.

Table Scans
Ein Handler muss nicht zwangsläufig auf einen Index verweisen. Es lassen sich auch ganze einfache Tabellen durchlaufen. In den Statements entfallen dann logischerweise nur die Index-Zusätze, der Rest bleibt identisch:

HANDLER employees OPEN;
HANDLER employees READ FIRST;
HANDLER employees READ NEXT;
HANDLER employees READ PREV;
HANDLER employees READ LAST;
HANDLER employees CLOSE;

Pagination
Handler lassen sich wunderbar dafür einsetzen, Ergebnisse aus Datenbanktabellen seitenweise anzuzeigen. Da sie die Ordnung aus dem Index ausnutzen, können Sie in Verbindung mit LIMIT gleich große Mengen Daten z.B. für eine tabellarisch Darstellung liefern:

HANDLER employees OPEN;
HANDLER employees READ unique_idx=(100000) LIMIT 10;
HANDLER employees READ unique_idx NEXT LIMIT 10;
HANDLER employees READ unique_idx LAST LIMIT 10;
HANDLER employees CLOSE;