HTML5 & Forms

Als Ergänzung zu meinem XForms-Vortrag in der FH, hier ein paar nette Details zu den Neuerungen von HTML5/Forms. Jaja, was für eine Überaschung. Okay, nach dem Tod von XHTML2 (und demnach die Integration von XForms in XHTML) auch wieder nicht…

Ganz allgemein scheint Dive Into HTML5 aber auch empfehlenswert zu sein, wenn auch noch in Arbeit. Nett gemacht.

Eine URL mit Parameter richtig escapen – für Flash(vars)

Aufgabe: Es muss via Flashvar eine URL an ein Flash übergeben werden, welches diese dann aufrufen und die Daten nutzen soll.

Problem: Die Flashvars bestehen auf einer Aneinanderreihung von {key}={value} Parametern (verknüpft mit dem „&“). Dabei muss {value} komplett urlencodiert sein. Also die *gesamte* URL als solche. Das Flash wiederum liest den Parameter ein, decodiert(!) den entsprechenden Flashvar-Parametern und führt ihn dann aus. Dazu kommt, dass die Javascript-Funktionen escape() u.a. nicht *ausreichend genug* sind, um alle Zeichen zu kodieren. Tests mit „*“ oder „+“ führen schweren Fehlern, bzw. zu veränderten Parametern.

Lösung:

Das erste Geheimnis ist simpel, aber wichtig. Die Kodierung muss *zweimal* angewendet werden. Das erste Mal für jeden Parameter der eigentlichen URL (ich gehe mal davon aus, das die Parameterschlüssel immer gültig gewählt sind) und das zweite Mal für die gesamte URL. Damit erhält das Flash nach der ersten Rückumwandlung der Flashvar immer noch eine URL, wo alle Inhalte kodiert sind.

Das zweite Geheimnis ist nicht ganz so trivial, allerdings gibt es auch hierzu Lösungen. Im Internet findet sich eine nette Gegenüberstellung der Methoden escape, encodeURI und encodeURIComponent. Kurzes Fazit: escape < encodeURIComponent. Aber auch letztere wandelt einige Zeichen nicht um, die bei der Verwendung mit Flash Probleme machen. Diese Zeichen (~!*()‘) und das + müssen daher noch händisch kodiert werden.

function escapeAdvanced(s) {
	var r = encodeURIComponent(s);
	var replacements = {
		'~': '%7E',
		'+': '%2B',
		'!': '%21',
		'*': '%2A',
		'(': '%28',
		')': '%29',
		"'": '%27'
	};
	for (s in replacements) {
		if (replacements.hasOwnProperty(s)) {
			r = r.replace(s, replacements[s]);
		}
	}
	return r;
}

Für schönere Lösungen bin ich jederzeit offen 😉

Update: Mit UTF8 hat das ganze allerdings Probleme; wäre ja auch zu schön gewesen.

Auszeichnung mit dem Innovationspreis (Update)

Just for note: Im Rahmen unserer Diplomarbeit sind mein Kommilitone und ich gestern Abend auf der Weihnachtsfeier der Firma Opitz Consulting mit dem „Innovationspreis für Informatik (3. Platz)“ ausgezeichnet worden.

Weitere Informationen

Presse:

Ups, verrechnet.

In einer Javaanwendung habe ich vor einigen Tagen einen Faxpaus zum Besten gegeben, da muss man auch erstmal drauf kommen. Nicht eindeutig identifizierbare – sprich primitiven künstlichen Primärschlüssel – Entitäten mussten in eine Ausgabestruktur (JSON/XML) umgewandelt werden. Da nach aussen diese Entitäten aber einen – künstlichen – Schlüssel brauchen, habe ich entsprechend ein Konstrukt gebaut. In abgewandelter Form (natürlich im Original nicht mit System.out, aber es passt der Einfachheithalber genau):

System.out.print(entity1.getId() + '_' + entity2.getId());

wobei die Methode getId() jeweils ein primitives long zurückgibt. Und weil ich ja so sparsam bin, nutze ich auch nur ein Characterzeichen als Seperator. Jaja.. War eine äußerst sparsame Angelegenheit, die dazu führte, das ich heute wie verzweifelt gesucht habe, wieso denn kein String, sondern ein (hoher) numerischer Wert ausgegeben wird. Arg!

Für diejenigen, die diese Anekdote bis hierhin nicht verstanden haben: Macht nichts, scheinbar kein Programmierer 🙂 Die Lösung: Ein Characterzeichen ist natürlich kein String, d.h. Java wird nicht automatisch daraus einen String erstellen. Dementspreched steht dort eine Formel a la „long + int + long“, und dies ist irgendwas, nur nicht das gewünschte.