Mittwoch,
02. März 2011

Die ersten Hinweise auf den Entwicklungszweig für YAML 4.0 habe ich ja bereits im Oktober letzten Jahres gegeben. In dem damaligen Beitrag habe ich allerdings noch nicht wirklich Informationen zur Version 4 gegeben sondern eher über die Dinge berichtet, die aus dem 4.0er Zweig in die Version 3.3 vorgezogen wurden. Heute hingegen werde ich ein bisschen aus dem Nähkästchen plaudern, wo die Reise bei YAML 4 hingehen wird. Und damit gehts auch gleich los ...

Namespaces

[Status: 85% fertig] Eines der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen. Beileibe nicht jedes CMS gestattet die vollständige Kontrolle über das ausgelieferte Markup. Wordpress weist beispielsweise dem <body> Element dynamisch eine Vielzahl von CSS-Klassennamen zu, was sich für Normalanwender auch kaum unterdrücken lässt. JavaScript Widgets wie Slider, Galerien etc. benötigen für den Zugriff auf ihr Markup sinnvolle IDs und Klassennamen – gleiches gilt für CSS Frameworks.

Für den Entwickler ist es gleichermaßen wichtig, möglichst selbsterklärende und konsistente Bezeichnungenzu verwenden, um die langfristige Wartbarkeit des Codes zu sicherzustellen. Eingänglich klingende, kurze Bezeichnungen wie “wrapper”, “post”, “page” usw. haben daher großes Konfliktpotential. Auf YAML bezogen kollidiert beispielsweise die von YAML verwendete CSS-Klasse .page mit der Verwendung, die Wordpress für die CSS-Klasse “page” vorsieht, die es dem <body> Element standardmäßig zuweist. Die Lösung hierfür heisst: Namespaces.

In YAML 4 werden daher die CSS-Klassen und IDs der Kernbestandteile des Frameworks mit einem Präfix versehen werden. Ein einheitlicher Namespace hat zudem den Vorteil, dass er (wir reden schließlich bei HTML/CSS von einfachen ASCII-Dateien) bei Bedarf leicht angepasst werden kann.

Grids sind Grids sind Grids

[Status: 100% fertig] Es ist immer eine gute Idee, Dinge bei ihren richtigen Namen zu nennen. Umschreibungen führen nur zu Missverständnissen. Nun, vor mehr als 4 Jahren erhielt YAML seine “Subtemplates”. Damals war YAML nicht viel mehr als eine universelle Vorlage für flexible 2- und 3-Spalten-Layouts und die “Subtemplates” kamen dem vielfach an mich herangetragenen Wunsch nach, auch innerhalb der Spalten eine einfache Möglichkeit zur horizontalen Gliederung von Inhaltsblöcken zu haben.

2006 war das Thema Grids noch ein volles Jahr von seinem internationalen Hype entfernt und so gab es mit der damals gewählten Bezeichnung keine Schwierigkeiten. Doch mit den immer populärer werdenen Grid-Layouts wurde auch klar, dass der Name “Subtemplates” alles andere als glücklich gewählt war, denn – und dass lässt sich in zahllosen internationalen Blogbeiträgen nachlesen – die Grid-Komponente wird nur selten auf den ersten Blick wahrgenommen, obwohl die Subtemplates bis heute eine der robustesten, mir bekannten Implementationen für flexible Grids sind. Aus diesem Grund wird es in YAML 4 eine Umbenennung der Klassennamen geben, um zukünfig Missverständnisse zu vermeiden: Aus der Bezeichnung “subtemplates” wird deshalb “grids”.

Auch in technischer Hinsicht wird das Grid-Modul von YAML 4 weiterentwickelt. Zwar war es schon bisher ausgesprochen robust und bot über die simple Zusatzklasse .equalize sogar die Erstellung gleichhoher Container auf Basis einer reinen CSS-Implementation an. Doch auf der anderen Seite war die Änderung/Erweiterung der im Framework-Kern mitgelieferten Raumaufteilungen für Frameworkanwender nicht gerade eingängig und einfach. Mit dem Grid-Modul von YAML 4 wird dieses Problem verschwinden. Indiviudelle Grids können dann mit einem CSS-Einzeiler erstellt werden, ohne dass die oben beschriebene Funktionalität eingeschränkt wird. Ein “Nachbau” eines pixelgenauen Gridlayouts mit YAML wird dann mit wenigen zusätzlichen Zeilen CSS zum Kinderspiel. Die aus meiner Sicht seit je her unsinnige Fragmentierung Grid-basierter Frameworkprojekte anhand der Basisbreite des Grids (950 Pixel, 960 Pixel, 978 Pixel, 1140 Pixel) ist damit für YAML-Anwender endgültig vom Tisch. Flexible, wie pixelgenaue Grids jedes beliebigen Rasters lassen sich mit weitgehend identischem Markup sehr einfach umsetzen.

Formulare, überall Formulare ...

[Status: 75% fertig] Die überwiegende Mehrzahl von Webseiten würde ohne Formulare gar nicht funktionieren. Wer kommt heute noch ohne mindestens ein Such- und Kontaktformular aus? Wenn Formulare aber so essentiell sind, warum sind sie dann noch kein Bestandteil des YAML-Cores? Gute Frage!

In YAML 4 werden die layoutunabhängigen Bestandteile des Formularbaukastens fest in den YAML-Core integriert. Mit dieser Umstellung geht auch eine leichtere Handhabung dieses Bausteins her, denn die Gestaltung der Formulare ist nun mehr oder weniger ein echtes Theming - die Austauschbarkeit bzw. Wiederverwendbarkeit individuell gestalteter Formulare wird damit deutlich einfacher.

API-Doku statt Lehrbuch

[Status: 5% fertig] Die Dokumentation ist seit vielen Jahren eine meiner größten Baustellen. Sie ist über die Jahre kontinuierlich gewachsen und hat mit > 130 PDF-Seiten eine Größe erreicht, die eher einem stetig aktualisiertem Online-Buch ähnelt als einer Dokumentation des Frameworks. Diese ausführliche Art der Projektbeschreibung ist für Neulinge zum einen sehr hilfreich, weil die Funktionsweise der einzelnen Bausteine bis ins Detail beschrieben ist, zu einem Großteil auch die Fallstricke der Problembrowser. Zum anderen ist es für jeden Neueinsteiger aber auch extrem mühsam, diese Informationsmengen zu durchforsten, wenn man sich mit dem System vertraut machen will. Zum dritten erzeugt der hohe Detailgrad (man denke auch an die Zweisprachigkeit und die parallele Verfügbarkeit online und als herunterladbares PDF) einen enormen Pflegeaufwand. Dieser ist mit den letzten Versionen immer mehr auf ein unverhältnismäßig hohes Maß angestiegen und ich muss hier gegensteuern.

Ich plane daher, die aktuelle Doku abzulösen durch eine Art Cheatsheet oder eine Kurzdoku, die nurmehr die Eigenschaften und Anwendung der einzelnen Bausteine des Frameworks beschreibt (also eine Art API-Dokumentation), jedoch nicht mehr das warum für jede einzelne CSS-Eigenschaft dokumentiert. Die bisherige Dokumentation wird als Entwicklerdokumentation in wahrscheinllich leicht verkürzter Form erhalten bleiben, jedoch nicht mehr mit jedem Pointrelease aktualisiert werden.

Projektstruktur

[Status: 25% fertig] Eines der größten Hürden für Neueinsteiger war und ist die aktuelle Struktur des YAML-Downloadpakets. An sich ist das keine neue Information, den derartige Diskussionen gab es schon früher – damals mit der Konsequenz, dass ich das “Simple Project” eingeführt habe, welches auch die Basis für die Arbeit mit dem YAML Builder liefert und seither für den Einstieg empfehle. Leider hat das bisher nicht so funktioniert wie gedacht. Deshalb wird es auch hier eine Umstellung geben.

Das Downloadpaket wird zukünftig mehr oder weniger dem entsprechen, was heute das Simple Project darstellt. Mit diesem Paket kann sofort gearbeitet werden, Pfadanpassungen sind nicht erforderlich. Die zahlreichen Layoutbeispiele sollen zukünftig in einem gesonderten Zip-Paket zum Download bereitgestellt werden. Diese Trennung ist schon deshalb sinnvoll, da in der Vergangenheit kleine Fehlerkorrekturen in den Layoutbeispielen ein neues Downloadpaket des Frameworks erzwungen haben.

Die Ordner- und Dateistruktur innerhalb des YAML-Ordners bleiben hingegen unangetastet, denn sie haben sich bewährt.

Darüber hinaus möchte ich auch die Beispiele etwas entschlacken. Dabei steht nicht im Vordergrund, zwingend deren Anzahl zu reduzieren aber doch das eine oder ander sinnvoll zusammenzufassen. Dafür sollen einige neue komplexere Beispiele hinzukommen, die u.a. den Umgang mit Media Queries zur Anpassung an verschiedenste Ausgabemedien zeigen. Auch hier ist YAML mit seinem flexiblen Ansatz extrem wandlungs- und anpssungsfähig.

Und wann geht’s los?

Anhand der Statuswerte lässt sich ja zum Teil abschätzen, wie weit die Arbeiten in den einzelnen Bereichen fortgeschritten sind. Was sich indess jetzt schon sagen lässt ist, dass mir momentan vorschwebt, der Version 4.0 eine öffentliche Betaphase zu gönnen und diese ist nicht mehr allzu weit entfernt.

Gute, ausgereifte Frameworks leben von ihren klaren Strukturen. Nur große Versionssprünge wie der von v3.x auf v4.0 erlauben es, größere Änderungen/Weiterentwicklungen in einem solchen Projekt vorzunehmen und aufgrund der wunderbar großen Nutzerbasis möchte ich an dieser Stelle mit einer öffentlichen Betaphase die Tür ausdrücklich offen stehen lassen für weitere Vorschläge aus der Community, die durchaus noch in die Version 4.0 einfließen können.

In diesem Sinne, 2011 wird spannend ...


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.