WPF-Blogger.com [Language: de]

Jetzt Backbone.js lernen: Konzept WPF-Blogger

Norbert Eder [MVP] — 2012-01-31T12:00:00

Bevor es so richtig mit Backbone.js los geht, möchte ich das neue Konzept von WPF-Blogger vorstellen, die grundlegenden Features beschreiben und über den generellen Aufbau als solchen berichten. Es sind zahlreiche Änderungen angedacht. Aus dem Feed-Aggregat soll eine Site mit weit mehr Benutzer-Interaktion entstehen. Einige Funktionalitäten stellen jedoch auch lediglich Überlegungen dar, die ich gerne zur Diskussion freigeben möchte. Aber mehr in dieser Vorstellung.

Status Quo

WPF-Blogger war ursprünglich als reines Feed-Aggregat konzipiert. Ziel war es, Feeds zum Thema WPF zu bündeln und Interessierten gesammelt zur Verfügung zu stellen. Folgende Features wurden in der ersten Version inkludiert:

Feed-Aggregation von ausgesuchten Blog-Feeds
Mehrsprachigkeit
Registrierung von neuen Feeds
Übersicht aller registrierten Feeds
Archiv inklusive Suche
Gesamtfeed und Sprachfeeds
Statistiken

Umgesetzt wurde die Website mit ASP.NET und WebForms und ganz, ganz wenig JavaScript.

Feed-Aggregat

Für das Aggregieren der Feeds läuft ein eigener Job, der zeitgesteuert sämtliche Feeds hin auf Neuigkeiten prüft bzw. bereits importierte Artikel aktualisiert. Dieser bleibt durch die Neuentwicklung der Website unberührt, da alle wesentlichen Funktionen enthalten sind.

Quo vadis?

Das ursprüngliche “Konzept” war hauptsächlich auf mich persönlich zugeschnitten. Es sollte eine Stelle sein, an der ich alle interessanten Blogs zum Thema WPF sammeln kann. Da dies auch für andere von Interesse sein konnte, hatte ich mich damals kurzer Hand entschlossen, eine eigene Website online zu stellen.

Im Laufe der Zeit hat sich gezeigt, dass das Interesse für diese Site da ist, jedoch fehlt vielen (auch mir) die Möglichkeit selbst Informationen einzustellen bzw. gute Inhalte zu teilen - kennt man schließlich auch von anderen Webangeboten. So das Feedback.

Nun gut, aber wie sieht es um den geplanten Funktionen aus?

Login über Drittanbieter. In der ersten Implementierungsphase wird Twitter implementiert. Als Erweiterung sollen Facebook und Google Plus ebenfalls angeboten werden, um möglichst wenige auszuschließen. Gewisse Funktionalitäten sind nur im eingeloggten Zustand möglich.
Suche. Eine Suche war bis dato über das Archiv bereits möglich. Dies wird weiterhin möglich sein, soll aber präsenter platziert werden.
Sprachauswahl. Wie bisher soll auch die Sprachauswahl weiter bestehen bleiben. Durch diese wird bestimmt, aus welcher Sprache Ergebnisse anzuzeigen sind. Die generelle Sprache der Website ergibt sich durch die Browsersprache.
Sharing Content. Es soll möglich sein, einzelne Artikel über unterschiedliche Kanäle zu verteilen, um guten Content bestmöglich verteilen zu können. Angeboten sollen Twitter, Facebook und Google Plus werden. Zusätzlich soll es möglich sein, Artikel für das spätere Lesen zu markieren. Dies kann wahlweise in der Applikation selbst (man muss angemeldet sein) oder über die Anbindung von Drittanbietern (Read It Later etc.) geschehen.
Statistiken. Diese sollen helfen, gute und interessante Inhalte schnell aufzufinden. Diese beziehen sich auf Topics, Autor und Aufrufen.

Nachfolgend findet sich ein Screen-Mock, der den Aufbau im ausgeloggten Zustand näher beschreibt.

Loggt sich der Benutzer ein, erhält er neue Möglichkeiten. Im ersten Schritt ist angedacht, ein Blog bzw. einen neuen Artikel einzustellen. Unter den Aktionen (rechts oben) können dann benutzerspezifische Einstellungen vorgenommen werden. Der Rest der Seite bleibt unverändert.

Allgemeine Verwendbarkeit

Eines der Ziele dieser Umsetzung ist, dass die entstehende Anwendung breiter eingesetzt werden kann. Sie soll den Grundstock für Feed-Aggregationen bieten, jedoch nicht auf diesen speziellen Anwendungsfall beschränkt bleiben.

Eingestellte Blogs und Artikel

Sämtlicher eingestellter Inhalt, der nicht aus einer vertrauenswürdigen Quelle stammt wird geprüft. D.h. ein neu eingestelltes Blog wird nicht automatisch aggregiert, sondern landet auf einer Liste von zu prüfenden Quellen. Damit soll zum Einen vermieden werden, dass Spam in der Auswahl landet, zum Anderen ist es durchaus sinnvoll, sich zuerst die Erlaubnis des Blogbetreibers einzuholen (wenn dies im Internet offensichtlich auch kaum üblich ist).

Neue eingestellte Artikel werden ebenfalls geprüft und freigeschalten. Auch hier soll es vermieden werden, dass Spam publiziert wird. Beiträge von Benutzern, die bereits 2 (oder eine andere zu konfigurierende Anzahl) freigeschaltete Artikel eingestellt haben, werden automatisch publiziert, da diese als vertrauenswürdig eingestuft werden. Dies kann über die Administration jederzeit rückgängig gemacht werden.

Administration

Die Administration soll im Wesentlichen folgende Funktionen bieten:

Benutzerverwaltung
Verwaltung der Blogs
Verwaltung der eingestellten Beiträge (Beiträge via Blog-Feeds werden in dieser Liste nicht behandelt)
Verfügbare Sprachen
Diverse Einstellungen

Die Administrationsseite wird Benutzern mit entsprechender Rolle über die Aktionen angeboten.

Nichtziel

Es ist kein Ziel von WPF-Blogger, die gesamten Inhalte anzuzeigen. Der Autor soll honoriert werden. Aus diesem Grund werden auch weiterhin nicht die gesamten Beiträge angezeigt, sondern lediglich ein Teaser.

Offene Fragen / Feedback erwünscht

Es gibt meinerseits einige Überlegungen, die grundsätzlich gut zur Neuentwicklung von WPF-Blogger passen würden, bei denen ich mir allerdings nicht zu 100% sicher bin. Ich möchte sie an dieser Stelle zur Diskussion stellen, in der Hoffnung auf Feedback.

Bewertung

Von einschlägigen Seiten (siehe beispielsweise DotNetKicks oder der deutschsprachigen Umsetzung) ist man es gewohnt, Beiträge bewerten zu können, um so die Spreu vom Weizen zu trennen. Das ist grundsätzlich eine gute Sache. Im Endeffekt ist mein Ansatz aber der Aktualität gewidmet. Der Benutzer soll einen schnellen Überblick erlangen, was sich in den abgedeckten Bereichen tut. Nichts desto trotz sollte er - meiner Meinung nach - doch auch eine Rückmeldung erhalten, welcher Inhalt von anderen empfohlen wird. Anstatt einer direkten Bewertung kann dies aber auch durch die eigentliche Statistik-Auswertung geschehen. Links, die häufig geklickt werden, scheinen grundlegend interessanter zu sein, als solche mit wenigen Aufrufen. Daraus könnte eine Bewertung abgeleitet werden, ohne den Benutzer zu einer Bewertung zu nötigen.

Kommentare

Wünschenswert wäre eine Möglichkeit Kommentare zu hinterlassen. Die Ideallösung wäre, dass sämtliche Kommentare an das eigentliche Blog zurückfließen und dem Verfasser des Artikels zu Gute kommen. Allerdings habe ich hierfür noch keine zufriedenstellende Lösung gefunden, wodurch ich die gesamte Funktionalität in Frage stelle. Meinungen?

Ausblick

Der nächste Artikel der Serie über Backbone.js beschäftigt sich mit dem Thema der Suchmaschinen. Darin wird hinterfragt, für welche Teile der Website der Einsatz von Backbone.js tatsächlich geeignet ist. Soll heißen, welche Inhalte werden statisch ausgeliefert und welche erst durch den Client erstellt.

Jetzt Backbone.js lernen: Die Serie

Norbert Eder [MVP] — 2012-01-28T14:36:24

Nach der erfolgreichen Serie über Knockout.js und dem durchwegs positiven Feedback, möchte ich - wie bereits angekündigt - eine neue Serie starten. Diese beschäftigt sich mit Backbone.js. In dieser Vorabinformation möchte ich kurz darauf eingehen, was der Leser erwarten darf. Und das ist eine ganze Menge, da diese Serie einen gänzlich anderen Weg einschlagen wird.

Praxisbeispiel

Im Rahmen der Knockout.js-Serie wurden unterschiedliche Beispiele behandelt. Diese wurden möglichst nahe an der Realität gehalten, aber es mussten auch Teile konstruiert werden. Dies soll in dieser Serie anders sein.

Im Rahmen der Backbone.js-Serie wird ein bereits bestehendes Projekt neu implementiert. Konkret geht es um meine Website http://wpf-blogger.com. Diese aggregiert Feeds von Bloggern zu WPF, Silverlight und Windows Phone in mehreren Sprachen. Damit soll einschlägigen Entwicklern eine zentrale Anlaufstelle für aktuelle Tipps, Tricks und Techniken auf Basis der genannten Technologien geboten werden.

Diese Entscheidung hat mehrere Hintergründe: So besteht die aktuelle WPF-Blogger bereits unverändert seit mehreren Jahren und bedarf zahlreicher Neuerungen. Da mir eine Weiterentwicklung auf der aktuellen Basis wenig zielführend erscheint, habe ich mich dazu entschieden, auf aktuelle Technologien und Techniken zu setzen, auch wenn manches davon als Hype angesehen werden kann.

Was kann der Leser nun erwarten?

Da ein konkretes Projekt zur Umsetzung gelangt, wird die Backbone.js-Serie einen hohen Grad an Praxiswissen und - im Rahmen der Umsetzung gemachten - Erfahrungen aufweisen. Ideal, um sich ein Bild über diese Bibliothek zu machen und einen etwaigen eigenen Einsatz besser abschätzen zu können.

Ein weiterer Mehrwert besteht sicherlich darin, dass ich - als der Autor dieser Serie - Backbone.js gerade erst lerne. Daher sind zahlreiche Hinweise auf Fallen und Tücken zu erwarten, in die ich getreten bin - oder noch treten werde.

Großes Augenmerk werde ich auch auf die Themen Konzept und Testing legen.

Eingesetzte Technologien und Bibliotheken

Das Projekt soll aus aktueller Sicht folgende (Quasi-)Standards, Technologien und Bibliotheken umfassen:

HTML5
CSS3
jQuery
Backbone.js
.NET

Sollte sich die Notwendigkeit ergeben, weitere Bibliotheken zu verwenden, wird diese Liste entsprechend erweitert.

Hinweis: Die obige Liste setzt auf weit mehr als nur Backbone.js. Auch diese werden in dieser Serie teilweise besprochen/diskutiert. Das Hauptaugenmerk wird jedoch auf Backbone.js gelenkt.

Sourcecode / Sharing

Jeder soll sich den aktuellen Sourcecode ansehen, aber auch für eigene Projekte verwenden können. In der Knockout.js-Serie habe ich hierfür teilweise JSFiddle verwendet, ist aber in diesem Rahmen nicht sehr zielführend. Aus diesem Grund habe ich mich entschieden, das gesamte Projekt auf github zu hosten.

Inhalt

Die einzelnen Teile dieser Serie sind nicht im Vorab festgelegt, sondern ergeben sich aus der laufenden Entwicklung des Projektes. Die untenstehende Liste ist daher als flexibel anzusehen und wird ständig erweitert bzw. auf dem aktuellen Stand gehalten.

Jetzt Backbone.js lernen: Die Serie (dieser Beitrag)
Jetzt Backbone.js lernen: Konzept WPF-Blogger
Jetzt Backbone.js lernen: Überlegungen zum Thema Suchmaschinen
Jetzt Backbone.js lernen: Grundlagen Backbone.js
Weitere Teile: TBD

Auf neue Teile wird zusätzlich über Twitter hingewiesen.

Feedback

JavaScript, HTML5 und CSS3 waren bis dato nicht mein Hauptscope. Daher ist es sehr wahrscheinlich, dass jede Menge meines Codes einfacher, schöner und besser geschrieben werden kann. Damit die Leser, die, so wie ich, ebenfalls keine Gurus auf diesem Gebiet sind, sich weiterentwickeln, hoffe ich auf zahlreiches Feedback. Darum bitte ich schon jetzt die Gurus unter meinen Lesern, mit ihrer Meinung nicht hinter den Berg zu halten.

Jetzt Knockout.js lernen: Mapping

Norbert Eder [MVP] — 2012-01-27T12:30:00

Im letzten Teil meiner Serie zu Knockout.js beschäftigen wir uns mit dem Mapping Plugin. In einigen der letzten Beispiele wurde mit JSON gearbeitet und so Daten simuliert, die vom Server stammen. Damit diese an eine View gebunden wurde, musste das ViewModel (welches Observables enthält) manuell aufgefüllt werden. Das Mapping Plugin bietet hier eine Unterstützung, die in diesem Anwendungsfall sehr viel Aufwand spart. Dieser Artikel zeigt wie es funktioniert.

Voraussetzungen

Damit das Mapping-Plugin verwendet werden kann, muss es via github bezogen werden. Hier der Direktlink zur aktuellsten Version. Das Script ist dann natürlich entsprechend einzubinden.

Grundlagen / Wiederholung

In den letzten Teilen dieser Serie wurden alle ViewModels manuell erstellt und sahen - mehr oder weniger - so aus:

     var MyViewModel = function() {

        this.title = ko.observable();    

        this.author = ko.observable();

        this.pages = ko.observable();

    }

Die Daten wurden dann so gesetzt:

    myViewModel.title('Ein Buch');

    myViewModel.author('Ein Autor');

    myViewModel.pages(500);

So musste das für jede Variable vorgenommen werden. Ein recht großer Aufwand, vor allem, wenn die Struktur komplexer wird.

Knockout.mapping kann diesen Aufwand für uns stark minimieren.

Beispiel

Nun aber zu einem Beispiel an Hand dessen wir uns ansehen, wie knockout.mapping funktioniert. Dazu benötigen wir eine View, die mit einer Schaltfläche ausgestattet ist. Bei einem Klick darauf werden JSON-Daten vom Server geladen und an die View gebunden. Hier vorerst die View:

    <div id="control">

        <input type="button" data-bind="click: loadData" value="Load data"></input>

    </div>

    <div id="data">

        <h2>Loaded Data</h2>

        <p>

            <span data-bind="text: userName"></span><br/>

            <span data-bind="text: tweetCount"></span>

        </p>

    </div>

Soweit noch nichts Neues, aber wenden wir uns der JavaScript-Seite zu.

    $(function(){

    var OverallViewModel = function() {

        this.loadData = function() {

            $.getJSON('http://dl.dropbox.com/u/30654117/Demos/JavaScript/Knockout.js/Mapping/data/data.json', function(data) {

                var viewModel = ko.mapping.fromJS(data);

                ko.applyBindings(viewModel, document.getElementById('data'));

            });

        };

    }

    var firstViewModel = new OverallViewModel();

    ko.applyBindings(firstViewModel, document.getElementById('control'));

    });

Hier wird ein ViewModel namens OverallViewModel definiert und an das DIV mit der Id control gebunden. Darin enthalten ist die Funktion loadData, welche bei einem Klick auf die Schaltfläche ausgelöst wird.

Darin wird im ersten Schritt das JSON vom Server bezogen. Im Anschluss wird ko.mapping.fromJS mit den Daten als Parameter aufgerufen. Das Ergebnis ist ein ViewModel, welches die entsprechenden Eigenschaften, welche im JSON definiert sind (als Observables) besitzt.

Der Vollständigkeit halber hier das JSON:

    {

        "userName": "Norbert Eder",

        "tweetCount": 10000

    }

Das resultierende ViewModel wird nun via ko.applyBindings an das DIV mit der Id data gebunden und die Daten kommen sofort zur Anzeige. Das einfache Beispiel ist fertig. Aber das Plugin kann noch mehr.

Ins Mapping eingreifen

Meine erste Frage - und das wird vermutlich jedem so gehen, war:

So ein einfaches ViewModel ist ganz nett, aber was, wenn ich Funktionen, berechnete Eigenschaften etc. benötige?

Aber auch hierfür gibt es eine entsprechende Lösung.

Erweitern wir obiges Beispiel ein wenig. Zu den rudimentären Tweet-Informationen sollen nun einzelne Tweets hinzugefügt und angezeigt werden. Jeder Eintrag soll mit einer Schaltfläche bestückt werden, mit deren Hilfe ein Retweet durchgeführt werden kann. Auch das sollte nun recht einfach gehen, haben wir uns doch bereits mit Templates beschäftigt. Die Herausforderung ist jedoch, die Tweets mit einem eigenen ViewModel zu versehen, welches eine entsprechende Funktion retweet anbietet, um eben diese Aktion ausführen zu können.

Zuerst aber ein Blick auf die Daten, zwecks Übersicht der durchgeführten Änderungen:

    {

        "userName": "Norbert Eder",

        "tweetCount": 10000,

        "tweets": [

            {

                "content": "Ein Testtweet der mit Sicherheit 140 Zeichen nicht überschreitet."

            },

            {

                "content": "Knockout.js ist schon eine sehr feine Sache!"

            },

            {

                "content": "Bin schon gespannt auf Backbone.js. Soll auch nett sein."

            }

        ]

    }

Nun muss die View umgebaut und mit einem Template versehen werden, auch noch nicht spektakulär:

    <div id="control2">

        <input type="button" data-bind="click: loadData" value="Load data"></input>

    </div>

    <div id="data2">

        <h2>Loaded Data</h2>

        <p>

            <span data-bind="text: userName"></span><br/>

            <span data-bind="text: tweetCount"></span>

        </p>

        <div data-bind="template: { name: 'tweet-template', foreach: tweets }"></div>

    </div>    

    <script type="text/html" id="tweet-template">

        <p data-bind="text: content"/>

        <input type="button" value="Retweet" data-bind="click: retweet"/></input>

    </script>

Interessant ist das ViewModel, oder besser gesagt, sind die beiden ViewModels, da für die Anzeige eines einzelnen Tweets ein weiteres ViewModel (nennen wir es TweetViewModel) definiert werden muss. Immerhin möchten wir eine Funktion unterbringen. Darin sehen wir nun auch bereits den ersten Trick:

    var TweetViewModel = function(data) {

        ko.mapping.fromJS(data, {}, this);

        this.retweet = function() {

            alert("retweeted");

        };

    }

Die Funktion retweet ist einfach und zeigt hier lediglich einen Alert an. Zumindest kann so die Funktionalität getestet werden. Interessanter ist, dass das ViewModel Daten als Parameter übergeben bekommt und diese via ko.mapping.fromJS auf sich selbst appliziert. Damit werden für die in den Daten enthaltenen Eigenschaften korrespondierende Observables am ViewModel erzeugt. Erster Teil erledigt.

Nun muss noch ein Weg gefunden werden, eine Instanz von TweetViewModel pro Item zu erzeugen. Dazu muss das Haupt-ViewModel ein wenig adaptiert werden.

Hinweis: Dieses wurde mit einem anderen Namen als im einfachen Beispiel zu sehen, da es im gleichen Beispiel zu finden ist, Download siehe weiter unten.

Sehen wir es uns an:

    var AnotherViewModel = function() {

        this.loadData = function() {

            $.getJSON('http://dl.dropbox.com/u/30654117/Demos/JavaScript/Knockout.js/Mapping/data/data2.json', function(data) {

                var viewModel = ko.mapping.fromJS(data, mapping);

                ko.applyBindings(viewModel, document.getElementById('data2'));

            });

        };    

    }

Abgesehen davon, dass die Daten nun von einer anderen Quelle bezogen werden, sticht diese Änderung ins Auge:

var viewModel = ko.mapping.fromJS(data, mapping);

Es wird ein neuer Parameter übergeben. Eine Konfiguration für das Mapping.

    var mapping =  {

        'tweets':  {

            create: function(options) {

                return new TweetViewModel(options.data);

            }

        }

    }

Darin wird ein create-Callback definiert, der sich auf das Array tweets bezieht (siehe Daten weiter oben) und für alle Einträge aus dem tweets-Array (siehe Daten) aufgerufen. Als Parameter werden options übergeben. Diese enthalten:

data: Ein JavaScript-Objekt mit den Daten
parent: Das Eltern-Objekt oder das Array zu dem die Daten gehören

Schlussendlich definiert die Zeile

return new TweetViewModel(options.data);

dass eine neue Instanz von TweetViewModel instanziiert werden soll. Die Daten werden als Parameter übergeben und innerhalb des ViewModel weiterverarbeitet (siehe weiter oben).

Das wunderschön gestaltete Ergebnis:

Fazit

Diese beiden Beispiele zeigen sehr schön, dass man sich mit Hilfe des Mapping Plugins jede Menge Schreibarbeit - und damit durchaus auch Fehler - sparen kann. Durch das mögliche Eingreifen in die Erstellung der ViewModels sind alle notwendigen Szenarien vorstellbar und keine Grenzen gesetzt.

Download / Showcase

Getestet werden können die beschriebenen Beispiele hier. Gleich untenstehend der Download des gesamten Paketes:

Feedback

Gerne nehme ich jegliches Feedback zu diesem Beitrag, als auch zur gesamten Serie zu Knockout.js entgegen. Hat dir die Serie geholfen? Hast du Anmerkungen, Anregungen? Fehlt ein Teil, sprich, wurde ein wichtiges Thema nicht besprochen? Teile es mir doch einfach mit und verfasse gleich einen Kommentar.

Jetzt Knockout.js lernen: Die Serie

MVC / Razor Style-Switcher – Quicky

Mario Priebe — 2012-01-26T13:25:17

Heute möchte ich zeigen, wie man sich einen einfachen Style-Switcher mittels jQuery in einem MVC / Razor Projekt einbauen kann. Den Basis-Style setzen wir zu Beginn, wenn die Seite zum ersten Mal geöffnet wird. Wichtig ist, das wir eine Id setzen, um in unserer jQuery Funktion dieses Element wieder zu finden. <link id="jQ" href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css")" rel="Stylesheet" [...]

Jetzt Knockout.js lernen: Formularvalidierung mit Undo

Norbert Eder [MVP] — 2012-01-25T11:30:00

In Jetzt Knockout.js lernen: Observables erweitern der Serie zu Knockout.js wurde gezeigt, wie Observables erweitert werden können. Als Beispiel diente eine Validierung auf Basis von einzelnen Observables. Nun hängen diese in der Regel aber in einem Formular zusammen, wodurch eine Gesamtvalidierung und eine damit verbundene Freischaltung von Schaltflächen bzw. weiteren Interaktionsmöglichkeiten einhergeht. Dieser Beitrag greift das Validierungsbeispiel auf und erweitert es im Rahmen dieser Anforderung.

Ausgangspunkt

Den Ausgangspunkt dieses Beitrags bietet dieses Beispiel, zu dem Florian einen sinnvollen Erweiterungswunsch hinterlassen hat:

Interessant wäre noch ein Save-Button, der nur aktiv ist, wenn es keine Fehler auf dem gesamten Formular mehr gibt, sowie ein Cancel- bzw. Undo-Button der bei eventuellen Fehlern, die Werte zurücksetzt auf den ursprünglichen Wert.

Aus meiner Sicht handelt es sich hierbei um eine gängige Anforderung, die ich natürlich aufgegriffen habe. Wer den Hintergrund des Beispiels erfahren möchte, kann dies hier vollständig nachlesen. Als Zusammenfassung: Das Beispiel zeigt, wie ein eigener Extender für Observables unter Knockout.js geschrieben werden kann, um einzelne Observables zu validieren. Als Validierung wurde eine Erweiterung hinsichtlich Pflichtfelder implementiert. Eine Gesamtvalidierung war nicht vorgesehen.

Gesamtvalidierung

Aktuell wird jedes Observable einzeln validiert. Entsprechend der Anforderung sollen nun zwei Schaltflächen für das Speichern, als auch das Zurückstellen auf die zuletzt gültigen Werte (im Fehlerfalle) hinzugekommen. Damit diese auch entsprechend freigeschalten sind, muss das ViewModel bekannt geben, in welchem Status es sich gesamt befindet. Dieser ergibt sich aus den Status jedes einzelnen Observables. Dies können wir uns berechnen lassen (ko.computed) und nennen wir hasErrors.

     self.hasErrors = ko.computed(function() 

    { 

       return self.title.hasError() || 

              self.author.hasError() || 

              self.pages.hasError(); 

    });

Hinweis: self ist eine Referenz auf this und wurde im Vergleich zum originalen Beispiel hinzugefügt, um innerhalb der anonymen Funktion auf die Eigenschaften und Funktionen des ViewModels zugreifen zu können.

Damit könnten nun auch bereits die beiden neuen Schaltflächen gesteuert werden:

    <input type="button" value="Save" data-bind="disable: hasErrors"></input>

    <input type="button" value="Undo" data-bind="enable: hasErrors"></input>

Auf die Speichern-Schaltfläche möchte ich an dieser Stelle nicht weiter eingehen, viel spannender ist hier der Undo-Button. Dieser soll ja - im Fehlerfalle - die zuletzt gültigen Werte hinterlegen. Dies bedeutet, dass diese erfasst werden müssen.

Nun ist es so, dass die einzelnen Eingabefelder eine value-Bindung besitzen und das Durchschreiben der Werte via valueUpdate auf den Wert afterkeydown gesetzt wurde. Das ViewModel wird also in Echtzeit aktualisiert. Darauf können wir also nicht aufbauen, da der Benutzer beispielsweise per Backspace alle Zeichen von “Beispiel” löschen könnte, durch die Echtzeit-Aktualisierung würde der zuletzt valide Wert durch “B” repräsentiert. Worauf wir uns jedoch hängen können ist das Verlassen des Fokus, also dem OnBlur-Ereignis.

Dazu brauchen wir eine Funktion, die uns den beim Verlassen vorhandenen - gültigen - Wert übernimmt:

    self.updateLastValidValue = function(observable) {

      if (!observable.hasError()) {

          observable.lastValidValue(observable());

      }

    };

Als Parameter wird das an das Eingabefeld gebundene Observable übergeben. So kann auch auf die durch den Extender geschriebenen Eigenschaften (siehe hasError) zugegriffen werden. Läuft die Validierung ohne Fehler, dann ist ein entsprechender Wert vorhanden und kann übernommen werden. Hierzu wird eine neue Eigenschaft namens lastValidValue mit dem Wert gesetzt.

Damit dies nun bei allen Eingabefeldern berücksichtigt wird, ist deren Bindung zu aktualisieren, hier an Hand der Titel-Eingabe:

    <input data-bind='value: title, valueUpdate: "afterkeydown", event: { blur: function() { updateLastValidValue(title); }}' />

So werden die Werte nun weiterhin in Echtzeit übernommen und zusätzlich beim Verlassen des Feldes die Funktion updateLastValidValue des ViewModels aufgerufen. Das ist allerdings noch nicht alles, denn ein etwaiger initial gesetzter Wert würde nicht berücksichtig werden. An dieser Stelle bietet es sich an, den bereits existierenden Extender (requireField) zu erweitern:

    ko.extenders.requiredField = function(target, message) {   

        target.hasError = ko.observable();

        target.validationMessage = ko.observable();

        target.lastValidValue = ko.observable();

        function validate(newValue) {

           target.hasError(newValue ? false : true);

           target.validationMessage(newValue ? "" : message || "* required");

        }

        function setInitialValueIfValid() {

            if (!target.hasError()) {

                target.lastValidValue(target());

            }  

        }

        validate(target());

        setInitialValueIfValid();

        target.subscribe(validate);

        return target;

    };

Neu ist die Funktion setInitialValueIfValid(). Diese wird beim Erstellen von requiredField durchlaufen (siehe den Aufruf direkt nach der initialen Validierung) und, wenn ein Wert vorhanden ist, lastValidValue mit dem entsprechenden Wert beschrieben.

Zu guter Letzt fehlt noch das tatsächliche Zurückschreiben der Werte, wenn die Undo-Schaltfläche geklickt wird. Dazu benötigen wir eine Funktion, nennen wir sie resetToValidValues:

    self.resetToValidValues = function() {

      self.title(self.title.lastValidValue());

      self.author(self.author.lastValidValue());

      self.pages(self.pages.lastValidValue());

    };

Außerdem muss die click-Bindung auf der Schaltfläche gesetzt werden:

    <input type="button" value="Undo" data-bind="enable: hasErrors, click: resetToValidValues"></input>

Fertig ist die Gesamtvalidierung des Formulars, inklusive der Möglichkeit, die zuletzt gültigen Werte zurück zu schreiben.

Ergebnis

An dieser Stelle nun zwei Screenshots, die die Implementierung visuell veranschaulichen. Der erste Screenshot zeigt das gesamte Formular ohne Validierungsfehler:

Und hier nun im Fehlerfalle:

Download / Showcase

Wie immer gibt es auch dieses Beispiel vollständig für eigene Tests. Unter http://jsfiddle.net/VgvuK/ findet sich die entsprechende Spielwiese. Wer möchte, kann sich dies auch unterhalb ansehen, sollte hierbei allerdings auf die Nutzung eines IE verzichten:

Fazit

Die notwendigen Erweiterungen der “Feld-Validierung” konnte in meinen Augen mit sehr wenig Aufwand auf eine Gesamtvalidierung erweitert werden, wodurch für den Benutzer sehr schnell ersichtlich ist, welche Aktionen zur Verfügung stellen. Ein äußerst sauberer Weg, durch die mögliche Auftrennung.

Feedback

Gerne nehme ich - wie immer - konstruktive Kritik, Anregungen und Anmerkungen entgegen. Einfach einen kurzen Kommentar hinterlassen, es findet sich sicherlich die eine oder andere Verbesserungsmöglichkeit.

Jetzt Knockout.js lernen: Die Serie

Google API jQuery UI 1.7.2 Theme Übersicht + Razor-Layout

Mario Priebe — 2012-01-24T15:02:13

Im folgenden eine kleine Übersicht von Google API jQuery UI 1.7.2 Designs, so vorbereitet, dass diese schnell im Header eines Razor Layouts eingefügt werden können. base <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/base/jquery-ui.css")" rel="Stylesheet" type="text/css" /> blitzer <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/blitzer/jquery-ui.css")" rel="Stylesheet" type="text/css" /> dark-hive <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/dark-hive/jquery-ui.css")" rel="Stylesheet" type="text/css" /> eggplant <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/eggplant/jquery-ui.css")" rel="Stylesheet" type="text/css" /> flick <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/flick/jquery-ui.css")" rel="Stylesheet" type="text/css" /> [...]

Jetzt Knockout.js lernen: Observables erweitern

Norbert Eder [MVP] — 2012-01-24T10:00:00

Im vergangenen Teil der Serie zu Knockout.js wurden benutzerdefinierte Bindungen behandelt. Dieser Teil beschäftigt sich nun damit, wie Observables auf eigene Bedürfnisse hin erweitert werden können. Knockout.js unterstützt das Lesen und Schreiben von Werten, als auch Benachrichtigungen bei Wertänderungen. In zahlreichen Fällen (zum Beispiel Validierung) möchte man dieses Verhalten jedoch erweitern. Dieser Beitrag zeigt, wie dies umgesetzt werden kann.

Extender zur Validierung erstellen

Knockout.js bietet mit Extendern eine Erweiterungsmöglichkeit an, sich an Observables zu hängen. Das nachfolgende Beispiel erweitert Observables durch die Möglichkeit einer Validierung.

Im ersten Schritt erstellen wir ein einfaches ViewModel, welches an eine View gebunden wird. Hier das ViewModel:

     function BookViewModel(title, author, pages) {

        this.title = ko.observable(title).extend({ requiredField: "Please enter a title" });

        this.author = ko.observable(author).extend({ requiredField: "Please enter an author" });

        this.pages = ko.observable(pages).extend({ requiredField: "" });

    }

    var viewModel = new BookViewModel("Windows Presentation Foundation 4.5 - Einführung und Praxis", "Norbert Eder", 400);

    ko.applyBindings(viewModel);

Und passend dazu die View:

    <div id="bookform">

        <h3>Title</h3>

        <p>

            <input data-bind='value: title' />

        </p>

        <h3>Author</h3>

        <p>

            <input data-bind='value: author' />

        </p>

        <h3>Pages</h3>

        <p>

            <input data-bind='value: pages' />

        </p>

    </div>

Soweit nichts Neues. Nun möchten wir aber, dass eingegebene Werte validiert werden. In diesem Fall beschränke ich mich darauf, Felder als benötigt zu definieren. Ein Extender wird daher benötigt. Um einen Extender zu schreiben muss ko.extenders um eine Funktion erweitert werden, nennen wir sie requiredField. Diese enthält als Parameter das Ziel der Erweiterung und eine Nachricht (die für die Anzeige einer Meldung verwendet werden kann).

    ko.extenders.requiredField = function(target, message) {   

        target.hasError = ko.observable();

        target.validationMessage = ko.observable();

        function validate(newValue) {

           target.hasError(newValue ? false : true);

           target.validationMessage(newValue ? "" : message || "* required");

        }

        validate(target());

        target.subscribe(validate);

        return target;

    };

Der Extender hängt dem Ziel zwei Eigenschaften hasError und validationMessage um. Die erste beschreibt, ob ein Validierungsfehler vorliegt, die zweite, welcher Fehler dies genau ist. Zusätzlich wird eine Funktion validate benötigt, welche die Validierung schlussendlich durchführt. Dies ist in diesem Beispiel recht einfach. So muss lediglich auf Vorhandensein eines Wertes geprüft werden. Ist dies nicht der Fall wird die über den Parameter message übergegebene Meldung angezeigt - wurde keine eigene Meldung übergeben, wird ein Fallback auf eine Standardmeldung verwendet.

Via validate(target()); wird eine initiale Validierung durchgeführt. Per target.subscribe(validate); wird ein Abonnement hinsichtlich Wertänderungen hinzugefügt, damit auch in diesen Fällen die Validierung durchgeführt wird.

Anschließend wird das ursprüngliche Observable zurück geliefert. Das war alles, was auf JavaScript-Seite zu implementieren war. Nun ist noch die View anzupassen, um etwaige Meldungen sichtbar zu machen.

    <div id="bookform">

        <h3>Title</h3>

        <p data-bind="css: { error: title.hasError }">

            <input data-bind='value: title, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: title.hasError, text: title.validationMessage'> </span>

        </p>

        <h3>Author</h3>

        <p data-bind="css: { error: author.hasError }">

            <input data-bind='value: author, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: author.hasError, text: author.validationMessage'> </span>

        </p>

        <h3>Pages</h3>

        <p data-bind="css: { error: pages.hasError }">

            <input data-bind='value: pages, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: pages.hasError, text: pages.validationMessage'> </span>

        </p>

    </div>

Für die Erweiterung der View wurden insgesamt drei Schritte unternommen:

Für die input-Felder wird die Aktualisierung des Wertes im ViewModel durch valueUpdate auf afterkeydown geändert, damit jede Änderung sofort im ViewModel wirksam wird und so schon zur Eingabe eine Validierung stattfinden kann.
Es wird ein span-Element eingeführt. Dieses enthält eine visible-Bindung auf die Eigenschaft hasError - ist also nur sichtbar, wenn ein Validierungsfehler aufgetreten ist. Der anzuzeigende Wert des span-Elementes wird auf die validationMessage gebunden.
Die umschließenden p-Tags wurden um eine css-Bindung erweitert. Dadurch wird bei Vorhandensein eines Validierungsfehlers eine CSS-Klasse error auf das Element gehängt, wodurch ein Styling einfach gemacht wird. So sieht es aus:

Download / Showcase

Das Beispiel kann unter http://jsfiddle.net/zHFEU/ getestet und bezogen werden. Untenstehend findet sich das JSFiddle in eingebundener Form, benötigt aber einen Browser ungleich IE.

Fazit

Dieses Beispiel hat gezeigt, wie einfach es möglich ist, ein Verhalten á la Validierung per Knockout.js und Extender zu realisieren. Auch hier gilt wieder, dass die Zuständigkeiten sauber getrennt sind und einfach gewartet werden.

Jetzt Knockout.js lernen: Die Serie

Jetzt Knockout.js lernen: Benutzerdefinierte Bindungen

Norbert Eder [MVP] — 2012-01-23T06:50:32

In den vorangegangenen drei Teilen der Serie über Knockout.js haben wir uns mit einer generellen Einführung, einer beispielhaften Bindung an Formulare und Listen als auch der Verwendung von Vorlagen beschäftigt. Dieser Teil beschäftigt sich nun mit der Möglichkeit der benutzerdefinierten Bindungen. So wird gezeigt, wann diese sinnvoll verwendet werden und wie sie denn überhaupt funktionieren.

Bindungen im Allgemeinen

Vordefinierte Bindungen stehen für die unterschiedlichsten Bereiche zur Verfügung. Abgedeckt werden Bindungen um Text und Darstellung zu kontrollieren (z.B. visible, text, html, css usw.), um mit Formular-Feldern zu arbeiten (submit, checked, value, etc.) und zur Ablaufsteuerung (foreach, if, ifnot, with).

Eine vollständige Übersicht findet sich in den Slides des ersten Teils.

Trotz der mannigfaltigen Möglichkeiten, besteht der Bedarf an eigenen Bindungen, gerade dann, wenn Werteänderungen spezielle Auswirkungen auf DOM Elemente haben sollen. Äußerst hilfreich sind benutzerdefinierte Bindungen auch dann, wenn Steuerelemente von Drittanbietern zum Einsatz kommen und so spezielle oder zusätzliche Attribute/Verhalten bedient werden sollen.

Grundlagen

Eine benutzerdefinierte Bindung wird durch folgenden Code erstellt, wobei myBindingName mit dem tatsächlichen Namen der Bindung zu ersetzen ist:

     ko.bindingHandlers.myBindingName = {

        init: function(element, valueAccessor, allBindingsAccessor, viewModel) {

        },

        update: function(element, valueAccessor, allBindingsAccessor, viewModel) {

        }

    };

Von Bedeutung sind die beiden Funktionen init und update:

init: Wird nur beim ersten Auswerten der Bindung aufgerufen. Ideal für die Initialisierung, beispielsweise dem Setzen von Eventhandlern.
update: Hier kann darauf reagiert werden, wenn sich gebundene Werte verändern. Der Aufruf erfolgt, wenn die Bindung das erste Mal angewandt wird und bei jeder Änderung des gebundenen Wertes. Sollte verwendet werden, um DOM Elemente auf Basis des geänderten Wertes zu manipulieren/aktualisieren.

Beide Funktionen sind mit insgesamt vier Parametern ausgestattet:

element: Das DOM Element der Bindung. Dadurch ist es nicht notwendig, dem Element eine Id oder Ähnliches zuzuweisen.
valueAccessor: Dahinter verbirgt sich eine Funktion, die Zugriff zum gebundenen Wert gibt. Die Funktion liefert ein Observable zurück, nicht den tatsächlichen Wert. Wird ein Ausdruck für die Bindung verwendet, dann wird dieser zurück geliefert.
allBindingsAccessor: Eine Funktion, die alle Bindungen auf dieses DOM Element zurück liefert.
viewModel: Das ViewModel-Objekt, das via ko.applyBindings gebunden wurde. Bei einer verschachtelten Bindung wird das gebundene Datenelement zurückgeliefert.

Doch sehen wir uns ein einfaches Beispiel an.

Beispiel

Sehen wir uns die benutzerdefinierte Bindung anhand eines kleinen Beispiels an. Es soll ein Eingabeformular geben. Hier können sowohl der Vor- als auch der Nachname erfasst werden. Die Daten werden darüber als Zusammenfassung angezeigt. Wird ein Wert in der Eingabe verändert, soll die Wertänderung in der Zusammenfassung mit Hilfe eines Fade-In-Effekts angezeigt werden.

Dazu ist ein einfaches ViewModel notwendig, welches an das User Interface gebunden wird:

    var viewModel = {

        firstName: ko.observable("Norbert"),

        lastName: ko.observable("Eder")

    };

    ko.applyBindings(viewModel);

Die View selbst sieht dann so aus:

    <div class="overview">

        <h2>First name</h2>

        <span data-bind="text: firstName"></span>

        <h2>Last name</h2>

        <span data-bind="text: lastName"></span>

    </div>

    <div class="data">

        <h2>First name</h2>

        <input data-bind="value: firstName" /><br/>

        <h2>Last name</h2>

        <input data-bind="value: lastName" /><br/>

    </div>

Soweit noch nichts aufregendes. Bei einer Werteveränderung, wird dies sofort in der Zusammenfassung nachgezogen. Nun soll aber noch der Einblendeffekt hinzukommen. Dazu erstellen wir eine benutzerdefinierte Bindung, die auf eine Wertänderung reagiert (update-Funktion).

    ko.bindingHandlers.fade= {

        update: function(element, valueAccessor) {

            $(element).hide().fadeIn(1000);

        }  

    };

Da lediglich auf die Wertänderung, ohne Berücksichtigung des tatsächlichen Wertes, reagiert werden muss, ist die update-Funktion ausreichend. Auch muss auf den Wert selbst nicht zugegriffen werden. Stattdessen wird lediglich das Element versteckt und via fadeIn eingeblendet.

Hinweis: Müsste auf den Wert reagiert werden, kann dieser via ko.utils.unwrapObservable(valueAccessor()) bezogen werden.

Damit dies auch tatsächlich funktioniert, muss die benutzerdefinierte Bindung noch in der View gesetzt werden:

    <div class="overview">

        <h2>First name</h2>

        <span data-bind="text: firstName, fade: firstName"></span>

        <h2>Last name</h2>

        <span data-bind="text: lastName, fade: lastName"></span>

    </div>

    <div class="data">

        <h2>First name</h2>

        <input data-bind="value: firstName" /><br/>

        <h2>Last name</h2>

        <input data-bind="value: lastName" /><br/>

    </div>

Fertig ist eine einfache Verwendung.

Download / Showcase

Das Bespiel kann unter http://jsfiddle.net/SvAHr/ getestet und bezogen werden. Oder aber auch untenstehend (IE streikt hier leider):

Fazit

Auch wenn das gezeigte Beispiel ein sehr einfaches ist, können benutzerdefinierte Bindungen sehr gut eingesetzt werden, um komplexe Verhalten zu steuern. Der Vorteil liegt darin, dass so wiederverwendbare Bindungen erstellt werden können. Im einfachsten Fall können darüber Standardverhalten/-einstellungen gesetzt werden, die jedoch nur an einer einzelnen Stelle zu implementieren/verwalten sind.

Jetzt Knockout.js lernen: Die Serie

Suche der BlogEngine.NET mittels Knockout.js verbessern - ein Praxisbeispiel

Norbert Eder [MVP] — 2012-01-19T15:25:52

In meiner Serie zu Knockout.js habe ich bereits gezeigt, was diese Bibliothek leisten kann. Nichts liegt also näher, als das eigene Blog ein wenig auf Vordermann zu bekommen. Stein des Anstoßes ist die Suche, die bei BlogEngine.NET sehr altertümlich wirkt und in meinem neuen Design daher bis dato nicht berücksichtigt wurde. Mit Knockout.js sollte eine verbesserte Variante schnell implementiert sein. Da die Suchergebnisse durch diverse Bots auch nicht indiziert werden müssen, kann Knockout.js bedenkenlos eingesetzt werden. Hier mein Erfahrungsbericht.

Kontext

Um den Kontext für diejenigen zu setzen, die sich weder mit der BlogEngine.NET beschäftigt haben, noch dies wollen, ein kurze Einführung wie die Zusammensetzung hinsichtlich der Suche ist und was alles benötigt wird. Wenn Erfahrungen mit eben diesem System bestehen, kann dieser Abschnitt übersprungen werden.

Die Suche der BlogEngine.NET besteht aus folgenden Teilen:

Klasse Search, welche die Suche übernimmt und Ergebnisse zurück liefert.
Ein Steuerelement SearchBox, welches ein Input-Feld, eine Schaltfläche und noch ein paar andere Dinge rendert. Das Input-Feld selbst reagiert auf ein Enter und leitet eigentlich nur auf die Suchseite weiter.
Ein Widget, welches das Steuerelement verwendet
Eine Suchseite (search.aspx), welche ebenfalls das angesprochene Steuerelement verwendet.

Das ist grob alles. Um das gesamte User Interface der Suche ersetzen zu können, ist es also notwendig, ein einzelnes Steuerelement (zum Einbinden im Header etc.), ein Widget und eine dedizierte Suchseite anzubieten.

Suche via AJAX ermöglichen

Die Suchfunktionalität besteht bereits (durch die Klasse Search). Diese sollte soweit bestehen bleiben, um auch mit zukünftigen Versionen kompatibel zu sein.

Was allerdings fehlt, ist ein Service, um dies nutzen zu können. Damit das Ergebnis am Client gut verarbeitet werden kann, liefert dieses JSON zurück. Zusätzlich werden auf Einstellungen des Blogsystems zurück gegriffen, um die Beschreibungen der Posts für die Ergebnisliste entsprechend zu kürzen. Der Code hierfür kann man sich dann im Download-Package ansehen.

Knockout.js ViewModel

Damit in der UI die notwendigen Bindungen gesetzt werden können, ist ein entsprechendes ViewModel notwendig, nennen wir es FastSearchViewModel. Welche Möglichkeiten soll es bieten?

Es muss der Suchbegriff abgefasst werden.
Der Benutzer kann wählen, ob Kommentare durchsucht werden sollen. Diese Information ist ebenfalls durch das ViewModel zu halten.
Die AJAX-Suche muss unter Angabe des Suchbegriffs durchgeführt werden.
Eine Liste der Ergebnisse ist zur Verfügung zu stellen.
Der Benutzer möchte Rückmeldungen á la “Keine Suchergebnisse” erhalten. Diese müssen angeboten werden.
Die Suche kann theoretisch dreimal auf einer Seite vorkommen (Suchfeld, Widget und Suchseite). Dieser Umstand ist zu berücksichtigen (wichtig für die Datenbindung auf einen bestimmten Bereich, da sonst alle Suchmöglichkeiten mit derselben Bindung ausgestattet werden).
Schlussendlich bedarf es noch Kleinigkeiten, wie das Zurücksetzen des Eingabefeldes bei einem Klick bzw. dem Auslösen der Suche bei Betätigen der Enter-Taste.

All diese Dinge wurden im nachfolgenden ViewModel berücksichtigt.

     var FastSearchViewModel = function (containerElement) {

        var self = this;

        self.container = containerElement;

        self.searchValue = ko.observable('');

        self.includeComments = ko.observable(false);

        self.foundItems = ko.observableArray();

        self.showNoItemsFound = ko.observable(false);

        self.hasSearchValue = ko.computed(function () { return self.searchValue().length > 0; }, self);

        self.hasResult = ko.observable(false);

        self.notExecuted = ko.observable(true);

        self.search = function () {

            var dto = { "searchTerm": self.searchValue(), "includeComments": self.includeComments() };

            $.ajax({

                url: "uri/to/searchmethod",

                data: JSON.stringify(dto),

                type: "POST",

                contentType: "application/json; charset=utf-8",

                dataType: "json",

                success: function (result) {

                    self.foundItems = ko.observableArray();

                    if (result.d.Posts && result.d.Posts.length > 0) {

                        for (var i = 0; i < result.d.Posts.length; i++) {

                            self.foundItems().push(new ResultViewModel(result.d.Posts[i].Title, result.d.Posts[i].Content, result.d.Posts[i].Link));

                        }

                        self.showNoItemsFound(false);

                        self.hasResult(true);

                    } else {

                        self.showNoItemsFound(true);

                        self.hasResult(false);

                    }

                    self.notExecuted(false);

                    ko.applyBindings(self, self.container);

                }

            });

        };

        self.inputChanged = function (sender, event) {

            if (event.keyCode === 13 && self.hasSearchValue()) {

                this.search();

            }

        };

        self.clear = function (sender, event) {

            self.searchValue('');

            self.hasResult(false);

            self.showNoItemsFound(true);

            self.notExecuted(true);

        };

        self.closePopup = function () {

            self.hasResult(false);

        };

    };

Zu beachten ist, dass die Ergebnisse aus dem AJAX-Aufruf in ein weiteres ViewModel geschrieben werden (ResultViewModel). Dies ist notwendig, damit die Bindungen greifen, die in einem Template für die einzelnen Einträge festgelegt sind. Hier der entsprechende Code:

    var ResultViewModel = function (postTitle, postContent, postLink) {

        this.title = ko.observable(postTitle);

        this.content = ko.observable(postContent);

        this.link = ko.observable(postLink);

    };

User-Interface

Das User-Interface muss nun die für die Suche notwendigen Elemente zur Verfügung stellen und die Bindungen festlegen. Hier das auf die Suchseite vereinfachte Markup:

    <div id="fastsearchpage">

        <input id="fastsearchbox" data-bind="value: searchValue, valueUpdate: 'afterkeydown', event: { keyup: inputChanged, click: clear }" placeholder="Suche" onkeypress="return noenter()"></input>

        <input id="fastsearchcomment" type="checkbox" data-bind="checked: includeComments">Kommentare inkludieren</input>

        <input type="button" id="fastsearchbutton" data-bind="click: search, enable: hasSearchValue" value="Durchsuchen"></input>

        <div id="fastsearchresult" data-bind="template: { name: 'searchresult-template', foreach: foundItems }">

        </div>

        <div id="nofastsearchresult" data-bind="visible: showNoItemsFound">

            <p>

                Keine Suchergebnisse.

            </p>

        </div>

        <div id="nofastsearchexecuted" data-bind="visible: notExecuted">

            <p>

                Geben Sie einen Suchbegriff ein und drücken Sie Enter oder die Suchen-Schaltfläche.

            </p>

        </div>

        <script type="text/html" id="searchresult-template">

            <div class="searchitem">

                <a data-bind="attr: { href: link, title: title }">

                    <span>

                        <strong data-bind="text: title"></strong>

                    </span>

                </a>

                <div data-bind="text: content"/>

            </div>

        </script>

        <script type="text/javascript">

            function noenter() {

                return !(window.event && window.event.keyCode == 13);

            }

        </script>

    </div>

Der Großteil der darin verwendeten Bindungen bringen zur Knockout.js-Serie nichts Neues. Interessant ist das Eingabefeld selbst:

    <input id="fastsearchbox" 

           data-bind="value: searchValue, valueUpdate: 'afterkeydown', event: { keyup: inputChanged, click: clear }" 

           placeholder="Suche" onkeypress="return noenter()">

    </input>

Dieses selbst hat eine Bindung auf searchValue um den eingegebenen Suchbegriff in das ViewModel durchzuschreiben. Ebenfalls wird das Ereignis OnKeyUp abonniert um auf das Betätigen der Enter-Taste hin zu prüfen, da in diesem Fall die Suche ausgelöst werden sollte. Beim Standardverhalten der value-Bindung ist es nun aber so, dass zum Zeitpunkt des Auslösens des Ereignisses (und des Verarbeitens in der Funktion des ViewModels) der eingegebene Wert noch nicht bekannt ist. Das liegt daran, dass die value-Bindung erst beim Verlassen des Fokus die Bindung selbst aktualisiert.

Um aber derartige Anforderungen abzudecken, steht der zusätzliche Parameter valueUpdate bereit. Darüber lässt sich konfigurieren, zu welchem Zeitpunkt die gebundene Eigenschaft des ViewModels aktualisiert werden soll. Folgende Möglichkeiten stehen zur Verfügung:

change: Das ist die Standardeinstellung und aktualisiert das ViewModel wenn der Fokus zu einem anderen Element geht.
keyup: Die Aktualisierung findet beim Loslassen des Tastendrucks statt.
keypress: Das ViewModel wird aktualisiert, wenn eine Taste gedrückt wurde. Hier ist anzumerken, dass dieses Ereignis mehrfach ausgelöst wird, wenn der Benutzer auf der Taste bleibt.
afterkeydown: Hier wird das ViewModel aktualisiert, sobald der Benutzer beginnt, ein Zeichen einzugeben. Diese Auswahl eignet sich bestens dazu, wenn das ViewModel in Echtzeit aktualisiert werden soll.

Stellen wir also valueUpdate auf afterkeydown, steht beim Auslösen der Suche der durch den Benutzer eingegebene Suchbegriff bereit.

Hinweis: Zusätzlich wird beim OnKeyPress noch die Funktion noenter() aufgerufen. Diese dient lediglich dazu, ein Submit eines eventuell vorhandenen Formulars zu verhindern.

Binden des ViewModels

Damit die Bindungen angezogen werden, muss ko.applyBindings aufgerufen werden. Wie bereits oben angesprochen, kann die Suche selbst mehrfach auf der Seite vorkommen. Damit nicht alle an dasselbe ViewModel gebunden werden (und dadurch anspringen, sobald es in einem der Felder eine Aktion gibt), sollte überprüft werden, wie viele Vorkommen vorhanden sind und an jedes eine eigene Instanz des ViewModels gebunden werden.

Das Ergebnis

Für die Verwendung unter BlogEngine.NET ist nun nicht mehr viel zu tun und weniger relevant, da lediglich Widget-Control (als Host) implementiert werden muss etc. Dies kann sich der interessierte Leser im Download genauer ansehen.

Das Resultat kann sich jeder hier im Blog ansehen, da alle Suchmöglichkeiten auf dieser Implementierung beruhen.

So sieht die Einbindung des Suchfeldes aus:

Und hier noch die Suchseite:

Download / BlogEngine.NET Package

Der Download ist über die BlogEngine.NET Gallery verfügbar. Darin befindet sich die Erweiterung zur BlogEngine.NET selbst, als auch die gesamte Implementierung. Wer diese Erweiterung für sein Blogsystem basierend auf BlogEngine.NET einsetzen möchte, findet weitere Informationen unter http://devtyr.com/fastsearch.html.

Feedback

Wie immer freue ich mich über jegliches Feedback. Sowohl zum Code selbst, als auch grundsätzlich zur Funktionalität der BlogEngine.NET-Erweiterung.

Asynchrones Befüllen einer ObservableCollection in einem ViewModel

Mario Priebe — 2012-01-14T18:46:21

Die Aufgabenstellung beschreibt, das innerhalb eine ViewModels Daten aus einer Datenbank ausgelesen und über der Netzwerkverbindung noch weiter verarbeitet werden müssen. Hier liegt es auf der Hand, dass eine asynchrone Lösung her muss, sprich es muss unter allen Umständen verhindert werden, dass die UI blockiert. Wie man das machen kann, zeige ich wie folgt: Ich [...]

Automatisiertes Ein- und Auschecken im Buildprozess

Mario Priebe — 2012-01-12T13:36:58

Möchte man nach einem Build, die Assembly in ein dafür bereitgestelltes Verzeichnis kopieren, kann man das recht einfach im Prä- und Postbuild-Ereignis im Visual Studio definieren. Hat man die DLL jedoch im TFS eingecheckt, muss man vor dem Kopieren dafür Sorge tragen, dass die Datei ausgecheckt wurde, ansonsten kann die eben wegen dem Schreibschutz nicht [...]

Jetzt Knockout.js lernen: Template verwenden

Norbert Eder [MVP] — 2012-01-12T07:00:00

Weiter geht es mit Knockout.js. Nachdem ich nun über den Einstieg gebloggt, als auch ein Beispiel bezüglich Formulare und Listen gezeigt habe, möchte ich mich mit diesem Beitrag mit dem Thema Templates beschäftigen und ein Beispiel implementieren, welches den Umgang damit aufzeigt. Vorlagen sind gerade bei wiederkehrenden Darstellungen (Listen etc.) eine hervorragende Sache, gibt es doch nur eine Stelle diese zu pflegen/ändern.

Aufgabenstellung

Konstruierte Beispiele sind immer so eine Sache, da oft der praxistaugliche Nutzen fehlt. Daher habe ich mich dazu entschieden, einen Teil meines Blogs mit Knockout.js nachzubilden. Konkret geht es um den Bereich Lesestoff.

Wie nachfolgend abgebildet, setzt sich diese Liste aus zwei zusammengehörigen Teilen zusammen:

Die Jahresangabe und der dazugehörigen Statistik über die Anzahl der gelesenen Bücher und Seiten.
Die Liste der Bücher, die im entsprechenden Jahr gelesen wurden.

Wie man bereits vermuten kann, bietet sich diese Darstellung wunderbar für die Verwendung von Vorlagen an. Die Umsetzung dieser Liste mittels Knockout.js unter Verwendung von Vorlagen, ist nun das Ziel des nachfolgenden Beispiels.

Templates / View

Bevor ich mich den ViewModels zuwende, muss ein Plan bezüglich der Vorlagen her, da sich daraus der weitere Aufbau ergibt. Wie bereits oben erwähnt, setzt sich die Seite aus zwei Teilen zusammen, dem Jahr (sowie der dazugehörigen Statistik) und der Buchliste zum Jahr. Es bietet sich daher an, eine Vorlage für das Jahr selbst und eine weitere für die Buchliste zu erstellen.

Nun zur Vorlage für die Jahresdarstellung, welcher wir den Namen year-template geben. Dieses besteht aus einem h3-Tag für die Anzeige des Jahres. Hier erfolgt eine Datenbindung auf eine Eigenschaft year, die durch das ViewModel geliefert werden muss. Die Auflistung der Bücher selbst findet über eine unsortierte Liste statt. Diese bekommt über eine template-Bindung nun ein Template für die Darstellung eines einzelnen Buches gesetzt und durchläuft mittels foreach alle Einträge der Auflistung books.

Damit die Anzahl der Bücher und der Seiten dargestellt werden kann, muss da ViewModel diese Werte berechnen und zur Verfügung stellen. Dies soll durch booksCount und pages passieren.

     <script type="text/html" id="year-template">

        <h3 data-bind="text: year"></h3>

        <ul class="kastenlightul" data-bind="template: { name: 'book-template', foreach: books }">

        </ul>

        <p>

            <strong data-bind="text: booksCount"/> B&uuml;cher<br/>

            <strong data-bind="text: pages"/> Seiten<br/>

        </p>

    </script>

Im nächsten Schritt wird die Vorlage book-template definiert. Diese definiert nun, wie ein einzelnes Buch dargestellt wird. Die Darstellung erfolgt durch das year-template in einer unsortierten Liste, wodurch li-Elemente gerendert werden müssen.

Ein li-Elemente enthält nun die notwendigen Elemente zur Darstellung des Buches selbst, das ist nicht weiter aufregend. Interessant ist hier die attr-Bindung. Darüber können jegliche Attribute des betreffenden DOM-Elementes gesetzt werden. Dies ist besonders interessant für Link- und Image-Elemente, zumal hier zusätzlich meist mehrere Attribute zu setzen sind.

    <script type="text/html" id="book-template">

        <li class="kastenlight">

            <img data-bind="attr: { src: coverlink, alt: title }"/>

            <a data-bind="attr: { href: titlelink, title: title }">

                <span>

                    <strong data-bind="text: title"></strong>

                </span>

            </a>

            <br /> <span data-bind="text: author"/><br /> <span data-bind="text: pages"/> Seiten<br /><strong>Bewertung</strong>: <span data-bind="text: rating"/>/5

            <div class="buy">

                <a data-bind="attr: { href: amazonlink }" target="_blank">Auf Amazon kaufen</a>

            </div>

        </li>

    </script>

Was nun noch fehlt ist die Stelle, die den Stein nun tatsächlich ins Rollen bringt. Eine Stelle, die beim Öffnen gerendert wird und auf das erste Template verweist.

Dazu wird ein einfaches div-Element erstellt und die dafür notwendige Bindung gesetzt:

    <div data-bind="template: { name: 'year-template', foreach: years }">

    </div>

Über die template-Bindung wird nun die Vorlage year-template für jedes Vorkommen in years angewandt.

Hinweis: Für dieses Beispiel wurden die bereits vorhandenen Styles verwendet. Diese befinden sich natürlich im Download, der ganz unten zu finden ist.

ViewModels

Auf JavaScript-Seite müssen nun die obigen Anforderungen abgedeckt werden. Für das book-template wird eine Repräsentation eines Buches mit den angegebenen Eigenschaften benötigt.

    var BookViewModel = function(item) {

        this.title = ko.observable(item.title);

        this.titlelink = ko.observable(item.titlelink);

        this.coverlink = ko.observable(item.coverlink);

        this.author = ko.observable(item.author);

        this.pages = ko.observable(item.pages);

        this.rating = ko.observable(item.rating);

        this.amazonlink = ko.observable(item.amazonlink);

    }

Als Parameter wird ein Objekt übergeben, welches alle notwendigen Informationen hat und das BookViewModel auffüllt.

Hinweis: Die Daten werden in diesem Beispiel via JSON gehalten und könnten an einigen Stellen direkt verwendet werden, habe ich aber hinsichtlich der Übersichtlichkeit und der möglichen Erweiterungen nicht getan.

Zur Darstellung eines Jahres, wie in year-template gefordert, wird nachfolgendes ViewModel verwendet:

    var YearViewModel = function(initYear, initBooks) {

        var self = this;

        self.year = ko.observable(initYear);

        self.books = ko.observableArray();

        $.each(initBooks, function() {

                var item = new BookViewModel(this);

                self.books().push(item);

            });

        self.booksCount = ko.computed(function() {

            return self.books().length;

        });

        self.pages = ko.computed(function() {

            var pagesCount = 0;

            $.each(self.books(), function() {

                pagesCount += this.pages();

            });

            return pagesCount;

        });

    }

Dieses ist nun schon ein weniger interessanter, als dass es ein Array der Bücher für dieses Jahr enthält, als auch zwei berechnete Eigenschaften booksCount und pages.

Nun fehlt noch das ViewModel, welches als “Einstieg” dient und an das div-Element der View gebunden wird, sowie eine Auflistung der in den Daten enthaltenen Jahre enthält:

    var BooksViewModel = function() {

        var self = this;

        self.years = ko.observableArray();

        self.init = function(initialItems) {

            $.each(initialItems, function() {

                var year = new YearViewModel(this.year, this.books);

                self.years().push(year);

            });

        }

    };

Diesem ViewModel wird über die Funktion init das JSON übergeben, wodurch sich in weiterer Folge die gesamte Struktur aufbaut.

Nun noch die Instanziierung und das Anwenden der Bindungen via:

    var firstViewModel = new BooksViewModel();

    firstViewModel.init(jsonBooklist.years);

    ko.applyBindings(firstViewModel, $('booksCollection').get(0));

Fertig.

So sieht’s aus

Wenig überraschend sieht das Ergebnis dem Original sehr ähnlich :)

Fazit

In diesem Beispiel wurde der Umgang mit benannten Vorlagen gezeigt. Natürlich gibt es auch noch die Möglichkeit, Vorlagen dynamisch zu wählen oder überhaupt eine externe Template Engine zu verwenden.

Mir gefällt die einfache Art und Weise wie eine Problemstellung wie diese umgesetzt werden kann.

Download/Showcase

Dieses Beispiel kann nachfolgend herunter geladen werden. Wer möchte kann auch einen Blick auf die Online-Demo werfen.

Feedback

Wie immer freue ich mich natürlich auch hierzu über Feedback, schließlich kann man nie auslernen und es gibt immer etwas, das verbessert werden kann.

Jetzt Knockout.js lernen: Die Serie

Jetzt Knockout.js lernen: Formulare und Listen binden

Norbert Eder [MVP] — 2012-01-11T07:00:00

Aus der WPF-Welt kommend ist gerade das Thema MVVM und Datenbindung sehr interessant für mich (weil dadurch auch etwas verwöhnt). Mit Knockout.js ist dies nun auch in JavaScript komfortabel möglich. Aufbauend auf den einführenden Beispielen und den von mir bereitgestellten Slides habe ich mich gefragt, wie nun der Umgang mit Listen und Formularen stattfinden kann und gleich in die Tasten gegriffen, um dies zu testen. Das Resultat ist ein Beispiel und ein paar Erkenntnisse, die ich teilen möchte.

Aufgabenstellung

Als Zielsetzung soll eine HTML-Seite ein Eingabeformular für die Eingabe von Buchinformationen anbieten und die eingegebenen Bücher in einer Liste darstellen. Zudem soll eine einfache Validierung stattfinden. Zu lösen ist die Problemstellung durch Datenbindung und somit einer sauberen Trennung zwischen ViewModel und View. Eine Serverkommunikation ist nicht angedacht.

ViewModels

Für die Umsetzung dieses Beispiels dachte ich an zwei verschiedene ViewModels. Eines, nennen wir es BookViewModel dient der Bindung an das Eingabeformular. Es kann sich selbst validieren und auf den ursprünglichen Stand zurücksetzen. Dieses ist nachfolgend abgebildet.

     var BookViewModel = function() {

        this.title = ko.observable('');

        this.author = ko.observable('');

        this.pages = ko.observable('');

        this.errorMessage = ko.observable('');

        this.hasErrors = ko.computed(function() { return (this.errorMessage() != ''); }, this);

        this.reset = function() {

            this.title('');

            this.author('');

            this.pages('');

            this.errorMessage('');

        };

        this.validate = function() {

            this.errorMessage('');

            if (this.title().length === 0 || this.author().length === 0 || this.pages().length === 0) {

                this.errorMessage('All fields are required');

            }

        };

    };

Die einzelnen Eigenschaften sind Observables (ko.observable), wodurch Benachrichtigungen über Änderungen an den Abonnenten (in Falle dieses Beispiels nur das UI) versendet werden und die dargestellten Werte (in der UI) immer aktuell sind.

Mit hasErrors soll zudem gesteuert werden, ob eine Fehlermeldung anzuzeigen ist. Die tatsächliche Meldung ist in errorMessage zu finden. Beides wird über die Funktion validate gesetzt.

Wichtig: Bezüglich der observierten Eigenschaften ist mir aufgefallen (und das verhält sich auch unter WPF/Silverlight so), dass das direkte Zuweisen von Werten zu Observables (diese sind als Funktionen abgebildet), diese natürlich überschreiben und somit keine Überwachung mehr stattfindet. Daher immer so darauf zugreifen: this.title('Der neue Wert'); Andernfalls kann die Suche nach dem Fehler schon mal etwas länger dauern …

Ein zweites ViewModel, BooksViewModel, beinhält eine Auflistung aller “gespeicherten” Bücher und stellt eine Instanz des ersten ViewModels via currentBook zur Verfügung. Damit neue Elemente hinzugefügt werden können, wird addItem angeboten. Hier wird im ersten Schritt die Validierung ausgeführt. Ist diese erfolgreich, wird das neue Buch in die Auflistung übernommen. Zusätzlich gibt es noch die Funktion clear. Diese setzt lediglich die Liste zurück.

Hinweis: Für die Darstellung der Liste habe ich auf das knockout.simpleGrid zurück gegriffen.

Und das ist das BooksViewModel:

    var BooksViewModel = function(items) {

        this.items = ko.observableArray(items);

        this.currentBook = new BookViewModel();

        this.addItem = function(formData) {

            this.currentBook.validate();

            if (!this.currentBook.hasErrors()) {

                this.items.push({

                    title: formData[0].value,

                    author: formData[1].value,

                    pages: formData[2].value

                });

                this.currentBook.reset();

            }

        };

        this.clear = function() {

            this.items.removeAll();

        };

        this.gridViewModel = new ko.simpleGrid.viewModel({

            data: this.items,

            columns: [

                {

                headerText: "Title",

                rowText: "title"},

            {

                headerText: "Author",

                rowText: "author"},

            {

                headerText: "Pages",

                rowText: "pages"}

            ],

            pageSize: 5

        });

    };

Zu beachten ist hier, dass die Auflistung der Elemente via ko.observableArray(items) erledigt wird. Also auch überwachbare Arrays sind möglich.

Das BooksViewModel enthält zusätzlich Initialdaten; die Erstellung und Übergabe ist weiter unten zu sehen.

View

Die View selbst ist nun nicht mehr besonders aufregend. Im Endeffekt werden ein paar div-Elemente verwendet und eine form, die zur Eingabe der Daten dient.

    <div id="booksCollection">

    <form data-bind="submit: addItem" id="newEntryForm">

        <div class="formArea">

            <h1>Add new Entry</h1>

            <div class="errorBox" data-bind="visible: currentBook.hasErrors">

                ERROR: <span data-bind="text: currentBook.errorMessage"/>

            </div>

            <div id="row">

              <div id="col">

                  Title

              </div>

              <div id="col">

                <input data-bind="value: currentBook.title" placeholder="Enter new book title"></input>    

              </div>

            </div>

            <div id="row">

              <div id="col">

                  Author

              </div>

              <div id="col">

                <input data-bind="value: currentBook.author" placeholder="Enter new author"></input>

              </div>

            </div>

            <div id="row">

              <div id="col">

                  Pages

              </div>

              <div id="col">

                <input data-bind="value: currentBook.pages" placeholder="Enter new pages count"></input>

              </div>

            </div>            

            <button type="submit">Add book</button>

        </div>

    </form>

    <div class="collectionArea">

        <h1>Books</h1>

        <div data-bind='simpleGrid: gridViewModel'></div>

        <button data-bind="click: clear">Clear books</button>

    </div>

    </div>

Eine interessante Geschichte ist die action des Formulares. Hier wird eine submit-Bindung auf die Funktion addItem erstellt. Wird nun der Submit-Button betätigt, werden die Daten aus dem Formular an diese Funktion übergeben.

Hinweis: Dies könnte auch ohne Formular und mit einer click-Bindung implementiert werden, da currentBook ohnehin die eingegebenen Daten enthält.

Das div-Element, das zur Anzeige der Auflistung herangezogen wird, enthält eine simpleGrid-Bindung auf gridViewModel (dieses wird über das SimpleGrid zur Verfügung gestellt und enthält die Auflistung aller Bücher).

Damit die angezeigte Liste zurückgesetzt werden kann, wird über das ViewModel die Funktion clear angeboten. Damit diese aufgerufen wird, reicht es, eine Schaltfläche mit einem click-Binding auf diese Funktion zu erstellen:

    <button data-bind="click: clear">Clear books</button>

Um die Bindungen zu aktivieren, muss noch ein wenig JavaScript hinzugefügt werden:

    var initialData = [

        {

        title: "Windows Presentation Foundation 4.5",

        author: "Norbert Eder",

        pages: 400}

    ];

    var firstViewModel = new BooksViewModel(initialData);

    ko.applyBindings(firstViewModel, $('booksCollection').get(0));

Hier werden lediglich Demodaten angelegt und bei der Erstellung des BooksViewModel-Objektes übergeben. Weit wichtiger an dieser Stelle ist der Aufruf ko.applyBindings. Damit wird das ViewModel an das Element gebunden, das durch den zweiten Parameter gefunden wird.

Hinweis: Wahlweise könnte der zweite Parameter auch weggelassen werden. In diesem Fall würde das gesamte Dokument nach dem Attribut data-bind durchsucht werden.

Ab diesem Zeitpunkt ist das Binding aktiv und die Werte werden synchronisiert.

So sieht’s aus

Hier nun die einzelnen Darstellungen der Website. Nachfolgend die Darstellung nach Öffnen der Seite:

Durch die Validierung wurde festgelegt, dass alle Eingabefelder einen zugewiesenen Wert besitzen müssen. Ist dem nicht der Fall, wird ein Fehlerhinweis angezeigt:

Download

Wer sich mit diesem Beispiel ein wenig spielen möchte, findet unterhalb die Möglichkeit dieses herunter zu laden, auch steht es auf JSFiddle zur Verfügung (wer den Internet Explorer verwendet, sollte sich das Beispiel herunter laden).

Fazit

Ein wenig HTML-Markup, ein wenig JavaScript-Code, Bindungen und ein paar Styles, fertig ist die Eingabemaske und die entsprechende Liste. Die einzelnen Teile lassen sich schön voneinander trennen und somit gut pflegen. Kein Code der Felder, Werte etc. aktualisiert. Auf das Wesentliche reduziert. Eine feine Sache, die Lust auf mehr macht.

Feedback

Was kann man schöner, eleganter, einfacher lösen? Hast du hierzu Feedback? Lasse es mich bitte wissen!

Jetzt Knockout.js lernen: Die Serie

Jetzt Knockout.js lernen: Slides und Beispiele

Norbert Eder [MVP] — 2012-01-10T09:14:55

Knockout.js ist eine JavaScript Bibliothek, die es ermöglicht, Datenbindungen durchzuführen. Dadurch ist eine saubere Trennung zwischen ViewModel und View (als auch Model) möglich. Wer Erfahrung mit WPF und/oder Silverlight hat, der kennt die Vorteile bereits, wird auch hier das Pattern Model-View-ViewModel (oder kurz MVVM) verfolgt. Um mir selbst einen Überblick zu Knockout zu verschaffen, habe ich grundlegende Informationen und kleinere Beispiele in einer Präsentation zusammen gefasst, die ich an dieser Stelle teilen möchte.

Die Links zu den Beispielen sind zwar in den Slides vorhanden (können im Vollbildmodus geklickt werden), dennoch nochmals außerhalb: hier und hier. Sie sind auf JSFiddle gehostet (idealerweise nicht den Internet Explorer verwenden, da dieser offensichtlich beim Beziehen der eingebundenen JavaScripts daneben greift), dadurch kann gleich im Browser getestet und probiert werden.

Habe ich etwas Essentielles in der Präsentation vergessen oder kann man die Beispiele (den Code selbst) weiter verbessern? Ich freue mich über Feedback, bin ich doch selbst erst beim Erlernen.

Jetzt Knockout.js lernen: Die Serie

Buch: vier minus drei - Barbara Pachl-Eberhart

Norbert Eder [MVP] — 2012-01-09T10:39:00

Ein Schicksal, das erschüttert. Ein Buch, das Mut macht. Es gibt wohl nichts Tragischeres, als von einem Moment auf den anderen seine Familie zu verlieren. Barbara Pachl-Eberhart hat es erlebt: Im März 2008 starben ihr Mann und ihre beiden kleinen Kinder durch einen Verkehrsunfall. In diesem Buch schildert die Autorin, wie sie sich ihrem Schicksal stellte. Wie sie mit Mut und bedingungsloser Offenheit den Weg in ein neues Leben fand. Und wie das starke innere Band zu ihren verstorbenen Lieben ihr dazu die Kraft gab. Ihr ergreifender Bericht zeugt von menschlicher Größe und einem unerschütterlichen Glauben an den Sinn des Lebens.

Manche haben es in ihrem Leben wahrlich nicht einfach. Meist denkt man selbst “Es erwischt ja eh nur die anderen”. In diesem Fall schlug das Schicksal gar nicht so weit entfernt zu. Über Jahre hinweg bin ich knapp an der Unglücksstelle, welche die Familie von Barbara Pachl-Eberhart zerriss, vorbei gefahren. Kenne die Gegend, kenne den besagten Bahnübergang. Sehr dramatisch und “nahe” genug, um auch mal darüber nachzudenken, wie man selbst mit einem derartigen Ereignis umgehen würde. Wie Barbara Pachl-Eberhart damit umgegangen ist und wie es geschafft hat, wieder einen Sinn im Leben zu finden, das beschreibt sie in diesem Buch. Aber Achtung: Es geht wirklich nahe und zeitweise muss man eine Pause einlegen, um das Erzählte und eigene Gedanken zu sortieren und ein wenig Abstand zu bekommen. Das erklärt auch, warum ich fast ein Jahr an diesem Buch gelesen habe.

Dennoch, das Buch handelt nicht nur von Traurigkeit, einer Tragödie, nein, es gibt auch all denjenigen, die ähnliches erfahren mussten, Trost und Hoffnung auf ein gutes Ende. Wem nichts dergleichen widerfahren ist, dem wird gezeigt, dass ein kurzer Moment der Unachtsamkeit, eine Familie/ein Leben nachhaltig ändern kann.

Für dieses Buch möchte ich keine Bewertung geben, zu heikel ist mir das besprochene Thema. Doch möchte ich eine klare Empfehlung aussprechen. Unbedingt lesen!

Weitere von mir gelesene und bewertete Bücher finden sich unter Lesestoff.

Neues Jahr, neues Blogdesign. Warum eigentlich?

Norbert Eder [MVP] — 2012-01-05T14:54:53

Ich muss ja gestehen, dass ich nicht unbedingt der begabteste Designer bin. Vielleicht gefallen mir aber auch deswegen schlichte Designs wesentlich besser als aufwändige. Da mir von Zeit zu Zeit das Aussehen meines Blogs auf die Nerven geht, hatte ich mir für 2012 vorgenommen, daran zu schrauben. Schneller als gedacht fand der erste Schwung der Umstellung statt. Aber was genau hat mich gestört und warum habe ich mich für eine bestimmte Lösung entschieden?

Inhalt zählt

Für mich zählt der Inhalt, ohne Schnörkel. Lese ich online Inhalte, dann möchte ich mich ganz darauf konzentrieren und so wenig als möglich abgelenkt werden. Dies ist schwierig, wenn zahlreiche Widgets, Sidebars und Co. durch die Gegend schwirren und mich an eine andere Stelle (ver)leiten möchten. Ich als Leser möchte das aber nicht. Ich will den Inhalt, diesen eventuell kommentieren oder teilen. Mehr interessiert mich dann aber auch schon nicht mehr. Und mehr möchte ich meinen Lesern auch nicht zumuten.

Also weg mit all dem das stört. Den Rest an Stellen positionieren, die gefunden werden, aber nicht störend sind (wie in meinem Fall eine Platzierung am Ende der Seite). So geschehen mit meiner Sidebar und einer Box, die direkt unter dem Menü ihr Dasein fristete. Allerdings ist dabei Vorsicht walten zu lassen, mehr unter Analyse.

Meist wird auch eine Leserschaft vergessen: Diejenigen, die nicht Read It Later oder InstaPaper verwenden um etwas später zu lesen, sondern es schlicht und einfach ausdrucken. Kaum jemandes Blog verwendet für das Medium Print eigene Stylesheets, wodurch sämtliches unnötige Zeugs auf dem Ausdruck zu sehen ist. Unzumutbar. Abspecken und unbedingt auf den Inhalt reduzieren. So kann sich auch der Offline-Leser auf den Inhalt konzentrieren, mal davon abgesehen, dass seine Navigationsmöglichkeiten ohnehin anderer Natur sind.

Das Ergebnis ist nun eine Konzentration auf den angebotenen Inhalt. Ohne viel drum rum. So wie ich es mir oft auf anderen Seiten wünschen würde.

Lesbarkeit

Zum Thema Lesbarkeit fallen mir auf die Schnelle folgende Punkte ein:

Schriftfamilie/Schrift
Schriftgröße
Kontrast

Zur Schriftfamilie und Schrift lassen sich die unterschiedlichsten Meinungen und Auswertungen finden. Wichtig für mich war die Verwendung einer Web-Schriftart (siehe auch Google Web Fonts), da das Lesen am Bildschirm dadurch eindeutig erleichtert wird. Bei der Wahl der Schriftfamilie und der Schrift selbst habe ich mich jedoch auf meinen ganz persönlichen Geschmack verlassen.

Das Thema der Schriftgröße erachte ich mittlerweile als weniger wichtig (wobei ich auch hier auf Basis des erhaltenen Feedbacks nachjustiert habe), da per Browser-Zoom mal schnell korrigiert werden kann - durch den Benutzer.

Gestehen muss ich, dass ich auf das Thema Kontrast eindeutig zu wenig Rücksicht genommen haben. Sven hat mich darauf (nach einer ersten Version) aufmerksam gemacht und auch gleich einen passenden Link geliefert: http://contrastrebellion.com/ (unbedingt ansehen!). Wieder etwas gelernt und auch gleich umgesetzt.

Werden nun aber Sidebar und Co entfernt, verbreitert sich der Inhaltsbereich oft wesentlich. Gut, um viel Inhalt darzustellen. Schlecht für die Lesbarkeit, meint Thomas in seinem Feedback. Und recht hat er. Wie aber entgegen wirken?

Für die Darstellung von Fließtext (siehe sämtliche News-Seiten) kann dann gerne mal ein mehrspaltiges Layout herhalten. Das eignet sich allerdings so gar nicht für das Anzeigen von Sourcecode. Das heißt, an dieser Stelle muss man wohl einen Kompromiss eingehen. Gefällt mir nicht, muss ich aber mangels Alternativen.

Hast du eine Alternative? Dann lass es mich bitte wissen!

Ein weiterer Schritt die Lesbarkeit weiter zu erhöhen ist das Auflockern der Beiträge selbst. Definitiv ein Punkt der in Zukunft mehr Beachtung benötigt.

Inhalt finden

Was bringt der beste Inhalt, wenn er nicht gefunden werden kann. Mit aller Aufräumerei sollte bedacht werden, dass der werte Besucher auch noch das findet, das ihn interessiert. Und das ist in der Regel nicht die erste Handvoll an Beiträgen. Dies passiert in der Regel über drei Varianten (direkt auf einer Site):

Kategorien
Tags
Suche

Kategorien sind eine nette Variante den gezeigten Inhalt zu filtern. Mehr aber auch nicht. Vor allem auf News-Sites stellt die Hauptnavigation eben diese Filterung dar. In den meisten Blogsystemen sind Hauptnavigation und Kategorien jedoch getrennt.

Durch das Verschwinden der Sidebar fand diese Auflistung ein jähes Ende. Eigentlich wollte ich sie auch nicht, da sie von lediglich 0,2% der Besucher benutzt wurde. Doch das Feedback ließ nicht lange auf sich warten (Sebastian ist einer dieser 0,2% wie er meint). Also dann doch wieder rauf damit. Allerdings in einer platzsparenden Version, die sich aufklappen lässt, wenn tatsächlich benötigt. Zusätzlich empfinde ich einfache Icons als auflockernd und hilfreich beim erneuten Finden. Hier in aufgeklappter Form:

Für mich besonders interessant sind Tags. Eigentlich werden diese in den meisten Fällen sehr stiefmütterlich behandelt. Tags werden vergeben, finden sich in einer Auflistung oder einer Tag-Wolke wieder. Das war’s. Für meinen Geschmack nicht ausreichend.

Dennoch bedurften die Tags einer Verschönerung, vor allem, um auch eindeutig als solche erkannt zu werden, ohne notwendiger Weise “Tags” davor zu schreiben.

Exkurs: Eigentlich könnte eine Auswertung der Tags Kategorien ersetzen. Aus meiner Sicht müssten die Tags hinsichtlich ihres gemeinsamen Vorkommens ausgewertet werden. Tags, die nicht (oder nur selten) zusammen vorkommen (und eine bestimmte Relevanz haben) könnten als Kategorien angesehen werden. Durch das Schaffen von Verbindungen könnte darüber eine Navigation erfolgen/angeboten werden. Die Navigation würde sich aus den Inhalten ergeben und bietet zudem die Möglichkeit eine tiefgreifende Filterung durchzuführen. Allerdings erst geeignet, wenn sich die “Master-Tags” ermitteln lassen.

Bleibt schließlich noch die Suche. Ich weiß nicht wie es dir, werter Leser, damit geht. Die Statistik meines Blogs besagt, dass so gut wie niemand diese Funktionalität verwendet. Suchende kommen über Suchmaschinen. Alle anderen sehen sich in der Regel die letzten Einträge an, oder browsen via Tags, noch weniger über Kategorien. Aus diesem Grund habe ich mich entschlossen, das Suchfeld vorerst zu entfernen und zukünftig ein wenig Effort in ein besseres Tag-System zu stecken.

Analyse

Es ist sinnvoll darüber Gedanken zu machen, ob etwas aktuell Vorhandenes auch weiterhin benötigt wird, oder entfernt werden kann. Das ist aber noch nicht ausreichend. Die eigene Meinung muss nicht zwangsweise die der Leser entsprechen. Es empfiehlt sich also zu analysieren, ob das entsprechende Teil durch die Besucher verwendet wird. Ist dem nicht so, verhält sich der Fall recht einfach - entfernen. Findet jedoch eine Verwendung statt, sollte man seinen Entschluss nochmals überdenken (dies ist natürlich auch von der Intensität der Nutzung abhängig).

Eine Analyse des Klickverhaltens bringt einen guten Überblick, welche Teile der Site vom Besucher genutzt/als interessant empfunden werden. Eine gute Basis für zukünftige Entscheidungen.

Eine entsprechende Analyse kann beispielsweise via Google Analytics erfolgen, sofern eingesetzt. Sehr hilfreich an dieser Stelle ist die In-Page-Analyse, gibt sie doch sehr schnell einen Überblick darüber, welche Links geklickt werden und welche nicht. Entsprechende Auswertungsmöglichkeiten bringen aber auch die meisten Log Analyzer (wie AWStats und Co.) mit.

Feedback

Das Einbinden der Leser ist ein wichtiger Prozess um Rückmeldungen zu den bereits durchgeführten oder angedachten Neuerungen zu erhalten. Schließlich gestaltet man seinen Webauftritt nicht nur für sich alleine. Möglichkeiten hierzu finden sich viele, man wähle einfach aus den Social Networks, ziehe Designer, Kollegen, Freunde hinzu. Dennoch: Ohne ein klares Rahmenwerk helfen auch Feedbacks nicht.

Zum Schluss noch ein herzliches Dankeschön an: Michael, Sven, Alex, Sebastian, Thomas, Mario, Thorsten, Gordon und Peter. Die Reihenfolge wurde zufällig gewählt und hoffentlich wurde niemand vergessen.

Wenn auch du noch konstruktive Anregungen und/oder Anmerkungen hast, bitte einfach einen Kommentar hinterlassen. Ich freue mich natürlich auch über ein Gefällt mir.

Buch: Justifiers 4 - Zero Gravity - Nicole Schuhmacher

Norbert Eder [MVP] — 2012-01-02T09:54:15

Auf das Team der Justifiers wartet einer ihrer bis dahin gefährlichsten Aufträge. Sie sollen auf einem einsamen Vorposten eines Konzerns nach dem Rechten sehen, denn die Station hat jeden Kontakt eingestellt. Zwar sind sie bereits auf einiges gefasst – aber was den Justifiers auf Holloway II tatsächlich begegnet, übertrifft ihre schlimmsten Alpträume …

Im vierten Teil der Justifiers-Serie erzählt Nicole Schuhmacher die Geschichte eines zusammengewürfelten Justifiers-Team der United Industries. Dieses soll von einem entfernten System Informationen beschaffen, die zum Stichtag nicht geliefert wurden, zumal auch kein Kontakt mehr möglich ist. Doch was sie dort finden lässt den ursprünglichen Kurier-Auftrag sehr schnell in ein äußerst gefährliches Spektakel ausarten. Währenddessen findet sich die Auftraggeberin selbst in großer Gefahr wieder. Ein Anschlag auf sie und ihrem Forschungschef zeigt sehr schnell, dass die Anzahl der Feinde groß und der eingeschlagene Weg für den Konzern vielversprechend ist …

Das Gute vorweg: Die erzählte Geschichte ist sehr spannend und gut erzählt. Leider ist der Anfang ein wenig holprig und bedarf ein wenig Überwindung, sich da wirklich durchzukämpfen. Nach den ersten Kapiteln wird man jedoch wirklich belohnt und findet sich mitten im Justifiers-Universum wieder. Grundsätzlich sehr empfehlenswert, durch den schwachen Start wirkt sich dies jedoch negativ auf die Beurteilung aus.

Bewertung: 3/5

Weitere von mir gelesene und bewertete Bücher finden sich unter Lesestoff.

2011 Top 10 Posts

Jürgen Ebner — 2012-01-01T13:40:25

Das Jahr ist wieder vorbei, deshalb wird es Zeit ein Resümee zu ziehen und die Top 10 der meistgeklickten Posts zu betrachten. Model-View-ViewModel (MVVM) – 868 Silverlight 2.0 Crashkurs Teil 2 – Textbox, Textblock, Button und Controlls – 392 Silverlight: Glass Button – 193 “Metro” design guide v1.00 – 161 WP 7 Update – 140 [...]