simple Javascript HTML5 jQuery Form Validation

Formular Validierung hat noch nie Spaß gemacht und meistens beschränke ich die Validierung auf die Server-Seite. Doch bevor man ein Formular per AJAX abschicken will, ist es immer besser auch auf der Client-Seite die Eingaben zu validieren und dem Benutzer ggf. noch darauf hinzuweisen dass nicht alle notwendigen Informationen eingegeben sind, das erspart Frustration.

HTML5 ist dabei eine große Hilfe. Mit dem erweiterten Formularfeld Attribut type, sowie dem pattern und required Attribut übernimmt der Browser die Validierung. Per Javascript reicht dann die Suche nach Formular Elementen die required sind aber einen invalid Status haben:

var $form = $("#emailForm");
if ($form.find(":required:invalid").length === 0) {
  // alle Pflichtfelder validieren
 
} else {
  // Nicht alle Pflichtfelder validieren
}

Über CSS kann man die Formularfelder auch noch stylen je nachdem ob sie valid oder invalid sind. Wer noch „Nicht-HTML5-Browser“ unterstützten muss, könnte per Modernizr((Modernizr  – the feature detection library for HTML5/CSS3)) eine Weiche schalten und ein Javascript Plugin zur Valdierung nutzen, oder per Progressive Enhancement((Progressive Enhancement – Wikipedia Artikel)) das Formular einfach über die serverseitige Parameter Validierung überprüfen und ausgeben lassen – um die serverseitige Validierung kommt man auch mit der jQuery Zeile von oben nicht drumherum. Frontend Formular Validierung ist und bleibt ein UX-Enrichment((UX Enrichment – Die Bereicherung des Benutzer Erlebnis)).

Einstieg in Sass und Compass bei eigenen Projekten

Im vierten Quartal 2011 bin ich auf Sass bzw. Scss aufmerksam geworden, doch den ersten Einsatz dieser Technik habe ich dann bis Ende 2012 verschleppt.

Die Möglichkeiten die Sass bietet hatten mich damals schon direkt überzeugt, aber die Sorge, dass man in einem echten Kundenprojekt sich mit den neuen Möglichkeiten verzettelt waren auch berechtigt. Beim ersten Projekt hatten nicht alle Entwickler die gleiche Wissensbasis zu Sass und dadurch kam es häufig dazu dass die Kompilierung nicht überall gleich gut funktionierte, oder dass Änderungen direkt in die css-Datei geschrieben wurden und dann wieder verloren gingen, bzw. dank SVN mühsam in die Sass Datei übertragen werden konnten.

Beim zweiten Projekt fühlte man sich soweit, dass ein CSS Framework als Ruby Gem genutzt wurde und auch hier war die Gefahr des Vergaloppieren groß.

Mittlerweile schreibe ich nur noch Sass und habe Wege gefunden und beschreibe im folgenden Wege wie man die Technologie einem ganzen Team mit gemischten Hintergrund (Designer, Markup Artist, Entwickler) zugänglich machen kann.

 

Schritt 1: Einrichtung von Sass und Compass auf allen Arbeitsplätzen

Auf der Sass Installationsseite und der Compass Seite wird die Installation für alle gängigen Betriebssysteme (Win, Mac, Linux) erklärt. Vom Einsatz eines GUI-Tool rate ich jedem ab, mit einer geschickten Konfiguration kann man seinen gewohnten Arbeitsablauf (IDE/Editor usw.) beibehalten und ein kleines Terminal Fenster erledigt alle Sass-Aufgaben.

Am Ende von Schritt 1 muss auf jedem Arbeitsplatz der Befehl compass watch ausführbar sein, auch auf dem Entwicklungssystem und dem Produktivsystem.

 

Schritt 2: Konfiguration des Projektes

Das Code Repository muss so angelegt sein, dass jedes Teammitglied, nach einem Checkout im Wurzelverzeichnis des Projektes den Befehl compass watch aufrufen kann und ab diesem Zeitpunkt sich wieder der Sass Entwicklung widmen kann.

Dazu gesellt sich die config.rb an die Seite des Entwicklers, eine simple Textdatei im Wurzelverzeichnis in der ein paar Variablen festgelegt werden:

http_path = "/"
css_dir = "css" # Verzeichnis in dem nachher das CSS laden soll: zum Beispiel "webroot/css"
sass_dir = "sass" # Verzeichnis in dem die scss Dateien liegen
images_dir = "img"
javascripts_dir = "js"

output_style = (environment == :production) ? :compressed : :expanded # Steuerung über das Format des erzeugten CSS

Die letzte Zeile hat es in sich, mit folgenden compass watch Befehlen, kann hier direkt minifiziertes CSS für das Produktivsystem oder lesbares CSS für die Entwicklung erzeugt werden:

compass watch -e production --force // erzeugt miniziertes CSS
compass watch // bringt menschenlesbares und debugbares CSS zu Tage

Schritt 3: Arbeiten mit Sass

Nachdem diese Hürde genommen ist kann die Arbeit mit Sass durch starten. Die grundlegende Technik (Schachteln von CSS Regeln) muss jedem Teammitglied erklärt werden sowie die Funktion der &– und @extend Funktion. Eine Sass Schulung wie sie zum Beispiel bei Code School angeboten wird kann hier hilfreich sein. Wie bei jeder neuen Technik unterscheiden sich die Lernkurven innerhalb eines Teams und daher sollte man schauen dass die Technik langsam Einzug hält und nicht zu abgefahrene Nutzung von @mixins und @functions Mitglieder ausschließt.

Ein nettes Gimmick während der Entwicklung bietet auch die // und /* ... */ Kommentarfunktionen in Sass. Der // Kommentar, weist den Compiler an, diese Zeile zu ignorieren, während der /* ... */ Kommentar in der kompilierten Datei erscheint.

Tipp: Comeback der @import Regel

Jeder Web Performance Optimierer hasst die @import Regel die immer noch in CSS Dateien vorkommt. Doch bei Sass feiert diese Regel zurecht ein Comeback. Der Compiler von Sass erkennt die @import Aufrufe und kopiert daraufhin die genannte Datei in die zu kompilierende Scss Datei, bevor er sie dann komplett kompiliert.

Dadurch kann ein Projekt beliebig viele verschiedene Sass Dateien benutzen, die in der Ausspielung alle in einer CSS Datei zusammengefasst sind. Wenn das ganze noch minifiziert ist, ist ein großer Schritt in der WPO einfach so erledigt.

// Beispiel app.scss
@import "video";
@import "bootstrap";

// ab hier folgen eigene Style Definitionen
.. {
 &:...{

 }
 .. {

 }
}

Mit diesen Angaben sucht der Compiler nach folgenden Dateien: video.scss, _video.scss, bootstrap.scss, _bootstrap.scss und bindet diese im Erfolgsfall ein. Der Unterstrich im Dateinamen weist den Compiler außerdem noch dazu an, die Datei nur einzubetten und nicht selbst zu kompilieren. Ohne Unterstrich enstehen im /css/ Verzeichnis auch die Dateien video.css und bootstrap.css.

Tipp: Einbindung von Frameworks per Sass

Die Technik habe ich im Abschnitt hier drüber erklärt, aber in der Einleitung habe ich erwähnt dass man viele Dinge auch als Ruby Gem in ein Projekt einbinden kann.

Das haben wir bei einem Projekt getan und Foundation 4 eingebunden. Ungeschickt dabei stellte sich heraus, dass alle Teammitglieder auch das Foundation Gem installiert haben mussten und Gem Versionen die nicht der initial Version (mit der das Projekt gestartet wurde) entsprachen, erzeugten fehlerhaftes CSS.

Dank dieser Erfahrung nutze ich mittlerweile immer die Anpassungsfunktion auf der Website eines Framework Anbieters und binde diese Dateien dann fest in das Projekt ein. Ein Update oder eine Erweiterung des Frameworks kann dann immer über diesen Weg erfolgen, was auf den ersten Blick etwas umständlich erscheint, aber dadurch ist es allen Teammitglieder immer möglich auf ihren Geräten das Projekt selbst zu erzeugen und das ist eine Menge wert.

MTB-Villetour die Zweite 2014 Video

Am Sonntag (05.01.2014) wurde jeder mit fantastischen Wetter belohnt der im Rheinland sein Haus verließ.

Auch Patrick, Philipp und ich ließen es uns nicht nehmen um eine Runde durch die Ville zu starten. Das Lichtspiel im Wald war wirklich ein Traum. Die GoPro hat ihr bestes gegeben um das einzufangen und im Video gibt es ein kleines Best Of der Tour zu sehen. Die musikalische Untermalung kommt von incompetech.com und zwar das Stück Cold Funk.

Die Tour startete am Heiderbergsee vom Höhenweg aus, danach folgt man links dem Schluchtsee und folgt dort dem Trail. Ein kleiner Trail führt direkt zum Untersee, und an allen drei Seen vorbei. Der nächste Trail ist am „Ende“ des Donatussee, dort wo früher mal so ein Feuerturm in den Himmel ragte. Einen Sprung weiter hinter dem Swisstaler Türmchen gibt es dann die kleine Abfahrt und der letzte Trail ist hinter dem „Bombemkrater“ und führt einen bis auf den Berg von Walberberg.

"Cold Funk" Kevin MacLeod (incompetech.com) 
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/

Meine mobile Webseite ist langsam…

Ich wollte eigentlich „Deine mobile Webseite ist langsam…“ schreiben, aber das wäre gemein und vielleicht sogar falsch – und so stimmt der Betreff immerhin.

Bisher habe ich mich immer auf die „Responsive Alles Könner Rahmenwerke“ verlassen wie zum Beispiel Foundation oder Bootstrap und während man damit eine Seite entwickelt sitzt man im Büro, zu Hause oder sonstwo und hat Kabel-LAN, Kabellos-LAN, LTE oder HSDPA am Smartphone und schaut sich immer über diese Breitbänder die eigene Arbeit an.

Es hallt noch durch die Räume dass man vor dem Start der Umsetzung gesagt hat „Man müsse auf niedrig sowie hoch aufgelöste Displays achten“ aber diese Aussage hat man falsch verstanden, oder falsch gemeint.

weiterlesen

Das kannst Du auch schlechter, oder?

Wir streben alle nach höher, weiter, besser, schneller und dank der Wissens[ver]teilung im Web stehen jedem Menschen unzählige Ressourcen zur Verfügung seine eigene Arbeit jeden Tag zu verbessern – ganz für umsonst, es kostet nur Zeit und Willen.

Für mich habe ich den Weg gefunden, nachdem man ein Problem gelöst hat, sich nochmal zu fragen ob man das Ganze auch hätte schlechter lösen können. Wenn man diese Frage mit „Nein, das hätte ich nicht schlechter lösen können“ beantwortet, dann ist man auf der sicheren Seite, dass die selbst erstellte Lösung sich eher hinten an der Brillant-Schlange angestellt hat. Und man sollte nochmal kritisch über die eigene Arbeit schauen.

weiterlesen