VIE und Create.js: Warum In-place Editing so erfolgreich ist
Kommentare

Mit den JavaScript-Bibliotheken VIE und Create.js hat Henri „Bergie“ Bergius einen Volltreffer gelandet. Ob Symfony2 CMF, TYPO3 Neos oder Drupal 8: Etliche Top-10-CMS-Systeme stürzen sich auf die Bibliotheken.

Mit den JavaScript-Bibliotheken VIE und Create.js hat Henri „Bergie“ Bergius einen Volltreffer gelandet. Ob Symfony2 CMF, TYPO3 Neos oder Drupal 8: Etliche Top-10-CMS-Systeme stürzen sich auf die Bibliotheken. Doch warum tun sie das, und mit welchem Aufwand ist dies verbunden? Wir haben den Wahl-Berliner gefragt.

Gründe für VIE und Create.js

Drupal, TYPO3 und Symfony CMF haben sich für Bergius‘ In-place-Editing-Lösung entschieden, während WordPress und Joomla! noch zögern. Auf die Frage, warum man sich für VIE und Create entschied und nicht für andere Bibliotheken, die das gleiche tun, zähle Bergius mögliche Gründe auf:

  • Timing: Inline Editing war für alle CMSs in diesem Release-Zyklus ein Thema.

  • Standards: VIE und Create arbeiten mit den Web-Standards und nicht gegen sie.
  • Fokussierung: Create kümmert sich ausschließlich um Inline Editing. Nicht mehr, nicht weniger.
  • Lizenzierung: Dank der MIT-Lizenz kann jeder den Code ohne größere Querelen integrieren.
Schwierigkeiten mit den vielen Teilnehmern

Doch müssen wir bei so vielen Playern befürchten, dass es früher oder später etliche verschiedene Create-Versionen gibt? Wir fragten Bergius, ob er das künftige Schicksal seiner Projekte noch in den Händen hält:

Ich hoffe, dass die CMSs die Versionen meiner Bibliotheken so gut im Auge behalten werden, wie es ihr Release-Zyklus erlaubt. In jedem Fall ist Abwärtskompatibilität etwas, was wir ernstnehmen müssen, da diese Bibliothek auf Millionen von Servern installiert werden wird.

Was die Fragmentierung angeht, denke ich, dass sie mit VIE und Create eher zurückgehen wird, da es den CMSs nahelegt, RDFa und JSON-LD zu übernehmen. Das vergrößert die Chance auf Interoperabilität und gemeinsam verwendeten Code.

Der technische Aufwand hinter Create und VIE

Eines der großen Buzzwords hinter dem Erfolg des Inline Editings ist das Decoupling: Aus vormals monolithischen CMS-Systemen mit einer Datenbank und einem großen CMS werden Baustein-artige Strukturen aus Web Editing, einem Web Framework und einem Content Repository, die einzeln gewartet werden können und durch gleichbedeutende Konkurrenzprodukte austauschbar sind. Bergie erklärte uns, welchen Arbeitsaufwand man bei der Implementierung von Inline Editing in Content Management Systeme hatte:

Inline Editing ist eng verbunden mit zwei weiteren Bereichen eines CMS:

  • Wir müssen in CMS-Output-Templates bestimmen können, welche die editierbaren Dinge sind (normalerweise über RDFa-Annotationen)

  • Wir müssen Änderungen auf dem Server abspeichern können (normalerweise über ein RESTful API)

Das waren die beiden Features, in denen die meisten CMSs serverseitig Änderungen vornehmen mussten, damit Create.js möglich wird. Bibliotheken wie CreatePHP wurden eigens erstellt, um dies zu vereinfachen.

Zeitgleich wurden VIE und Create.js mit jeder CMS-Implementierung besser, da sie jedes mal neue Fähigkeiten hinzugewannen.

Es wird also ersichtlich, dass das Editieren an der Oberfläche viel weniger oberflächlich ist, als es aussieht. Doch wie schätzt Ihr den Aufwand ein, der dafür betrieben wird? Ist der Mehrwert so gravierend und werden sich die CMSs mit diesem Feature gegenüber den etablierten Lösungen durchsetzen? Oder wird sich die Arbeit langfristig nicht lohnen?

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -