Category Archives: Web

Kommentare in JSON

Fun Fact: Es gibt keine offizielle Möglichkeit in JSON-Daten Kommentare unterzubringen.

Gerade als Entwicklerteam, dass sich erstmals mit JSON, Javascript und Client-Programmierung beschäftigt, sind Kommentare eine gute Möglichkeit sich zu erklären. Deshalb war ich überrascht, dass es tatsächlich keine Kommentare in JSON gibt.

In den ersten Versionen des Standards gab es zwar Kommentare, aber nachdem Douglas Crockford nicht gefiel, was die Leute mit Kommentaren anstellten, hat er sie ersatzlos aus dem Standard entfernt.

Nichtsdestotrotz halte ich diese Entscheidung für völlig falsch. Es ist für mich einfach völlig unverständlich warum z.B. in einer “package.json”-Konfigurationsdatei keinerlei Kommentare möglich sind, um bestimmte Einstellungen anderen Entwicklern zu erklären.

Als Konvention könnte man sich aber z.B. darauf einigen, Kommentare in der Datenstruktur selbst unterzubringen und diese Daten einfach nicht verarbeiten. Beispiel:

{
   "__comment" : "Das hier ist ein Kommentar",
   "success" : true,
   "data": {
      "title": "Es",
      "author": "Stephen King", 
      "isbn": "1234567890"
   }
}

Für Puristen sicher ein Graus, aber leider so ziemlich die einzige Möglichkeit.

Eine längere Abhandlung und auch eine Erklärung der Historie findet sich im getiblog

HTML5 Friendly Markup in JSF 2.2

Ed Burns (Spec Lead für JSF) hat heute in seinem Blog ein paar Informationen zum Thema JSF 2.2 veröffentlicht: HTML5 Friendly Markup in JSF 2.2

Leider hat sein Blog-Parser den Beispiel-Code völlig zerpflückt, sodass nicht mehr viel zu erkennen ist. Als Quintessenz aus seinem Text entnehme ich, dass er in Zeiten von modernen Single Page Web-Apps, die immer mehr UI-Logik auf den Client verlagern, weiterhin Sinn und Nutzen sieht, aber sie mit JSF 2.2 einen (grossen) Schritt auf moderne Anforderungen zugehen möchten, in dem sie Entwiklern die Möglichkeit geben, Anwendungen in purem HTML5 schreiben zu schreiben und nur mit ein paar JSF-Anreicherungen zu versehen, um auf dem Server von JSF’ Stärken zu profitieren:

[fancy_list]

  • quick to build
  • maintainable
  • localizable
  • accessible
  • secure
  • device independent
  • good looking and fun to use

[/fancy_list]

(schamlos kopiert aus seinem Vortrag auf der Java One)

Wie soll das nun aussehen? Der Code in seinem Blogpost ist wie gesagt momentan leider nicht lesbar, aber in genanntem Vortrag gibt es ein kleines Beispiel, was kombiniert mit dem Code aus seinem Blog Post so aussehen würde:

<xmlns="http://www.w3.org/1999/xhtml"
     xmlns:jsf="http://java.sun.com/jsf" xmlns:f="http://java.sun.com/jsf/core">
<html>
  <head jsf:id="head">
    ...
  </head>
  <body jsf:id="body">
    <input type="color" jsf:value="#{colorBean.color} />
    <input type="date" jsf:value="#{calendarBean.date}>
      <f:ajax execute="@this" render="@form"/>
    </input>
  </body>
</html>

Für HTML5-Neulinge: die beiden Input-Felder nutzen 2 von den neuen Input-Typen und rendern eine browser-generierte Farbauswahl-Box und einen Datepicker (ganz ohne weitere Komponenten).

Ich denke man kann schon ganz gut sehen, wohin die Reise geht. Man hat nun die Möglichkeit komplett auf die JSF-UI-Logik und JSF-UI-Komponenten zu verzichten und sich für das User Interface auf pures HTML zu verlassen. Im HTML-Quellcode wird dann von JSF nur noch wenig zu sehen sein, ausser ein paar Anreicherungen für den Submit/Postback oder wenn etwas ajaxifiziert werden soll. Das passt dann auch gut zum neuen HTML5-Standard-Doctype.

Die Idee finde ich an sich gar nicht so schlecht und ist definitiv ein notwendiger Schritt, um JSF aus seiner angestaubten Ecke zu holen, wo alles auf dem Server passiert und der Client nur zum Anzeigen des Renderergebnisses und dem Postback der Daten dient. So funktioniert moderne Webentwicklung einfach nicht mehr.

Aber ist das wirklich ein überzeugendes Argument für die Zukunft von JSF? Werden dadurch mehr Leute JSF in neuen Projekten einsetzen? Die oben genannten Stärken treffen alle auch auf die Kombination (Single Page) Client-Side Webapp + REST-Schnittstelle (JaxRS) zu, was ich jedenfalls in einem komplett neuen Projekt JSF deutlich vorziehen würde.

Crockford on Javascript

Wer noch nie einen Vortrag von Douglas Crockford gesehen hat, dem empfehle ich ganz herzlich seine “Crockford on Javascript” Vorträge auf Youtube.

Douglas Crockford war lange Zeit Javascript Evangelist bei Yahoo und ist der Entdecker des JSON-Formats. Übrigens Entdecker und nicht Erfinder, denn wie er selbst mal in einem Vortrag hervorgehoben hat, musste dieses Format quasi in Javascript entdeckt werden, weil es elementarer Teil der Sprache ist.

Ich finde seine Vorträge äusserst faszinierend, wirken sie doch eigentlich extrem trocken, aber sehr fundiert und sind dann doch immer wieder mit zahlreichen Spitzen garniert. Neben zahlreichen Anekdoten, kann man eine Menge als Javascript-Entwickler lernen.

String.prototype.endsWith(str) in Javascript

In meinem Projekt bin ich letztens über folgende, doch sehr hässlichen Konstrukte gestolpert:

function onKeypress(element)) {
  if (jQuery(element).attr("id").indexOf(str) != -1)) {
    //dosomething
  }
}

Um hier zu erfassen, dass der Code überprüft, ob die ID eines Elementes einen bestimmten String enthält, braucht man schon etwas länger. Neben dem überflüssigen jQuery-Aufruf, um die ID zu ermitteln, fällt auf, dass hier eine String-Utility-Methode wie [highlight1]contains()[/highlight1], [highlight1]startsWith()[/highlight1] oder [highlight1]endsWith()[/highlight1] nützlich wäre, um die Lesbarkeit des Codes deutlich zu verbessern. Ich habe mich deshalb fix entschlossen, die entsprechenden Methoden Projekt-weit nachzubauen.

Da es im konkreten Beispiel ausreichend war zu überprüfen, ob ein String mit einem anderen String endet, befasse ich mich hier mit [highlight1]String.prototype.endsWith(str)[/highlight1]. Die sehr ähnlichen Methoden [highlight2]contains()[/highlight2] und [highlight2]startsWith()[/highlight2] lassen sich analog umsetzen.

Per Google findet man diverse Methoden wie [highlight1]endsWith()[/highlight1] in Javascript nachzubauen ist. Folgende drei Varianten habe ich mal genauer untersucht:

String.prototype.endsWith1 = function(str) {
  var lastIndex = this.lastIndexOf(str);
  return (lastIndex !== -1) && (lastIndex + str.length === this.length);
};

String.prototype.endsWith2 = function(s) {
  return this.length >= s.length && this.substr(this.length - s.length) === s;
}

String.prototype.endsWith3 = function(str) {
  return (this.match(str + "$") === str)
}

Aufgrund einer Diskussion auf stackoverflow hat mich auch noch interessiert, welche von diesen drei Varianten in modernen Browsern am schnellsten abläuft. Die Auswertung mittels jsperf hat mich dann doch überrascht. Zwar sind die Varianten 1 + 2 browserübergreifend mit geringem Abstand untereinander (aber weit vor Variante 3) am schnellsten, allerdings war Chrome 22 um Größenordnungen langsamer, Firefox war ungefähr 10 mal so schnell!

In mein Projekt eingebaut, habe ich dann Variante 1. Und um sicherzugehen, eine eventuell schon vorhandene Methode am String-Prototypen nicht versehentlich zu überschreiben, sollte man natürlich vorher noch überprüfen, ob der String-Prototyp nicht schon so eine Methode hat. Der komplette Code sieht so aus:

if (!String.prototype.hasOwnProperty("endsWith")) {
  String.prototype.endsWith = function(str) {
    var lastIndex = this.lastIndexOf(str);
    return (lastIndex !== -1) && (lastIndex + str.length === this.length);
  };
}

Obiges Beispiel im richtigen Code, sieht dann damit viel schöner aus:

function onKeypress(element)) {
  if (element.id.endsWith(str)) {
    //dosomething
  }
}