1. Data Binding in qooxdoo
Intelligente und umfassende Datenbindung für
moderne Webanwendungen in qooxdoo
Master Thesis - Martin Wittemann
martin.wittemann@1und1.de
HS-Karlsruhe 1&1 Internet AG
16.04.2009
11. Evaluation
Alternative
JavaScript
Frameworks
Frameworks
SproutCore Flex
SmartClient
12. Evaluation
Alternative
JavaScript Native
Frameworks
Frameworks Frameworks
SproutCore Flex
Cocoa
Eclipse Data
Binding
WPF
SmartClient
13. Features
• Binding of single values
• Binding of list widgets
• Binding of tree widgets
• Binding of JSON, XML, CSV
• Formating, Conversion, Filtering, ...
• Master detail view
• ...
14. Use Cases
• Synchronize two textfields
• Fill a list with data from a JSON file
• Fill a tree widget with data
• Connect to the twitter REST service
and display messages in a list
• ...
18. Store 1
Layers
Store 2
...
Abstract Store
Store N
Data Array
qooxdoo
Classes with Properties
Controller 1
Controller 2
Binding
...
SingleValue
Controller N
20. How could it work?
• Change notification needed
• Common way to access the data needed
21. How could it work?
• Change notification needed
• Common way to access the data needed
qooxdoo Properties
• Support for change events
• Generated accessors
28. Deep Binding
a:A c:B
+ child : b + prop :
b:B
+ prop : 12
29. Deep Binding
a:A c:B
<<binding>>
+ child : b + prop :
b:B
+ prop : 12
30. Deep Binding
a:A c:B
<<binding>>
+ child : b + prop : 12
b:B
+ prop : 12
31. Deep Binding
a:A c:B
<<binding>>
+ child : b + prop : 23
b:B
+ prop : 23
32. Deep Binding
a:A c:B
<<binding>>
+ child : b + prop : 23
b:B
+ prop : 23
33. Deep Binding
a:A c:B
<<binding>>
+ child : b + prop :
34. Deep Binding
a:A c:B
<<binding>>
+ child : b
d + prop : 78
d:B
+ prop : 78
35. Deep Binding
a:A c:B
<<binding>>
+ child : b
d + prop : 78
d:B
+ prop : 78
a.bind(quot;child.propquot;, b, quot;propquot;);
36. Realization
• Properties and events as a basis
• Using of the dynamic aspects of JavaScript
var value = targetObject[quot;getquot; + propertyName]();
52. Binding of other properties
var delegate = {
bindItem : function(controller, item, id)
{
controller.bindProperty(
quot;onlinequot;, quot;checkedquot;, null, item, id
);
}
};
controller.setDelegate(delegate);
53. Binding of other properties
var delegate = {
bindItem : function(controller, item, id)
{
controller.bindProperty(
quot;onlinequot;, quot;checkedquot;, null, item, id
);
}
};
controller.setDelegate(delegate);
„The delegate structure provides great extensibility. Well done!“
[Wayne Si]
55. Model
DataStore
Store Model Controller View
Data
56. Model
DataStore
Store Model Controller View
Data
57. Requirements
• Regular qooxdoo classes hold the data
• Properties with events on every change
• Can hold every JavaScript datatype
• Problem with data in native arrays
• No change events will be fired
58. Requirements
• Regular qooxdoo classes hold the data
• Properties with events on every change
• Can hold every JavaScript datatype
• Problem with data in native arrays
• No change events will be fired
Custom array implementation is necessary
89. Integration
DataStore
Store Model Controller View
Data
90. Integration
DataStore
Store Model Controller View
Data
91. The Data
[
quot;aquot;, quot;bquot;, quot;cquot;, quot;dquot;,
quot;equot;, quot;fquot;, quot;gquot;, quot;hquot;,
quot;iquot;, quot;jquot;, quot;kquot;, quot;lquot;
]
data.json
92. Application Code
var list = new qx.ui.form.List();
this.getRoot().add(list);
var controller = new qx.data.controller.List(null, list);
var store = new qx.data.store.Json(quot;data.jsonquot;);
store.bind(quot;modelquot;, controller, quot;modelquot;);
105. Layers
Twitter Store
Flickr Store
JSON Store
Gears Store
Data Array
Classes with Properties
qooxdoo
Object Controller
List Controller
Binding
SingleValue
Tree Controller
106. Outlook
• Remote model
• Virtual widgets support
• Table support
• Optimization
• Dynamic form widget
- Vorstellen (Thema und mich)
- Dauer erwähnen
- Grundlagen für Präsentation
- Keine lange qooxdoo oder JavaScript Einleitung
- sollte jeder einigermaßen kennen
- Was ist Data Binding?
- Nicht 100%ig definiert was dazu gehört und was nicht.
- Daten werden zwischen einer Quelle und einem Ziel synchronisiert.
- verschiedene Transformationen
- Hier, Model und View da es um UI Binding ging
- Was ist Data Binding?
- Nicht 100%ig definiert was dazu gehört und was nicht.
- Daten werden zwischen einer Quelle und einem Ziel synchronisiert.
- verschiedene Transformationen
- Hier, Model und View da es um UI Binding ging
- Was ist Data Binding?
- Nicht 100%ig definiert was dazu gehört und was nicht.
- Daten werden zwischen einer Quelle und einem Ziel synchronisiert.
- verschiedene Transformationen
- Hier, Model und View da es um UI Binding ging
- Warum braucht man denn Data Binding?
1. Man kommt schneller zu einem Ergebnis (Time to market)
2. Man bekommt viele Funktionalität geschenkt
3. Verringert das Fehlerrisiko da man getestete Komponenten verwendet
4. Dadurch hat man Vorteile den anderen Frameworks gegenüber bzw. holt deren Vorsprung wieder ein.
5. Der Wunsch besteht schon lange. Seit Mitte 2006 gibt es schon im qooxdoo eigenen Bugsystem 2 offe bugs für data binding.
Ganz kurz die wichtigsten Dinge ins Gedächtnis rufen.
Es gibt ein Event System von qooxdoo welches Änderungen von Werten propagieren kann.
Zum Speichern von Werten werden oft Properties im Framework verwendet. Für diese werden die typischen Zugriffsmethoden automatisch erzeugt.
- kleine Auffrischung der wichtigsten Dinge von JavaScript
- Alle Objekte sind assoziative Arrays.
- Funktionen an Objekten heißen Methoden
- Methoden sind nur als Wert eines Arrays abgelegt
- einige Möglichkeiten, diese methoden aufzurufen
- auf nummer 2 eingehen
Das sollten eigentlich genug Grundlagen gewesen sein damit wir direkt ins Thema einsteigen können. Bevor mit der Entwicklung des Data Binding für qooxdoo begonnen wurde, wurde eine ausgiebige Analyse gemacht.
- 1 1/2 Monate
- drei Bereiche: JavaScript, Alternative und Native
- JavaScript
- SmartClient: gute dokumentation
- dojo: viele stores
- Alternative
- Flex: sehr leichtgewichtig und gut für enzelwerte
- Native
- Cocoa: Gute Controller-Konzepte, jedoch laden der Daten nicht drin
- Eclipse: Sehr komplex, viel nötig um die Voraussetzungen zu schaffen
- Backend wurde überprüft aber es hat sich nichts geeignet
- 1 1/2 Monate
- drei Bereiche: JavaScript, Alternative und Native
- JavaScript
- SmartClient: gute dokumentation
- dojo: viele stores
- Alternative
- Flex: sehr leichtgewichtig und gut für enzelwerte
- Native
- Cocoa: Gute Controller-Konzepte, jedoch laden der Daten nicht drin
- Eclipse: Sehr komplex, viel nötig um die Voraussetzungen zu schaffen
- Backend wurde überprüft aber es hat sich nichts geeignet
- 1 1/2 Monate
- drei Bereiche: JavaScript, Alternative und Native
- JavaScript
- SmartClient: gute dokumentation
- dojo: viele stores
- Alternative
- Flex: sehr leichtgewichtig und gut für enzelwerte
- Native
- Cocoa: Gute Controller-Konzepte, jedoch laden der Daten nicht drin
- Eclipse: Sehr komplex, viel nötig um die Voraussetzungen zu schaffen
- Backend wurde überprüft aber es hat sich nichts geeignet
- gar nicht genauer drauf eingehen
- Auflistung nicht komplett
- Dient nur als Ausschnitt
- auch diese Liste ist nicht komplett
- man kann sich ja viele use-cases denken
- hier sind nur ein paar aufgelistet
Jetzt kommen wir endlich zu dem interessanten Teil, nämlich zum Aufbau der Data Binding Lösung für qooxdoo. Ziel war es, Daten zu laden und mit der Oberfläche zu synchronisieren.
- von links nach rechts
- Data: Service, Datei, ...
- DataStore: Verantwortlich die Daten zu besorgen und in das Model zu bringen
- Model: Hält die Daten, reine Datenhaltung aus der Data Binding Sicht
- Controller: Übernimmt die Synchronisation zwischen Model und View
- View: übliche qooxdoo widgets
- Aufteilung in UI- und Backend-Binding
- Trotz Backend, alles im Client
- Schichtenansicht
- Finden sich einige Teile wieder
- Basis ist qooxdoo
- für die stores eine abstrakte Basisklasse
- Models sind im groben einfache qooxdoo klassen
- Controller hat das SVB als Basis
- Synchronisation von Einzelwerten wie z.B. Strings, Booleans aber auch Referenzen
- Finden sich einige Teile wieder
- Basis ist qooxdoo
- für die stores eine abstrakte Basisklasse
- Models sind im groben einfache qooxdoo klassen
- Controller hat das SVB als Basis
- Synchronisation von Einzelwerten wie z.B. Strings, Booleans aber auch Referenzen
- Genau dieses schauen wir uns als erstes an
- zuerst die Basis klären
- Was braucht manzum synchronisieren
1. Änderungen mitbekommen
2. allgemeine Zugriffsmethoden
- JavaScript-Objekte gehen z.B. nicht
=> qooxdoo Properties!
- Unterstützung von change Events
- Automatische Generierung der Zugriffsfunktionen
- funktioniert auf allen Properties mit events im Framework
--> große Unterstützung schon vorhanden
- Keine langen reden
- Beispielhafter Ablauf
- Zwei Objekte einer gleichen Klasse mit einem Property
- a hat die 12
- binding aufsetzen
- initial wird die 12 synchronisiert
- Änderungen in a bewirken Änderungen in b
- umgekehrt aber nicht --> unidirektional
- bidirektional durch 2 bindings
- Code sieht es sehr übersichtlich aus.
- Konzept geht jedoch noch weiter
- Quelle eine Objekt-Hierarchie
- Binding über diese Hirarchie
- Auch hier wird die Zahl initial synchronisiert
- Änderungen werden übertragen
- Auch hier wird die Zahl initial synchronisiert
- Änderungen werden übertragen
- Auch hier wird die Zahl initial synchronisiert
- Änderungen werden übertragen
- Auch hier wird die Zahl initial synchronisiert
- Änderungen werden übertragen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- b wird auf null gesetzt
--> prop in c wird reseted (kein Fehler)
- d wird an stelle von c platziert
--> 78 wird synchronisiert
- Code sehr ähnlich
- Unterschied nur die property kette
- Kann beliebig lange werden, wenn die events dazu vorhanden sind
- Arrays können auch darin vorkommen
- Viel der Probleme wurde schon durch qooxdoo gelöst
- Sehr gut dass dies verwendet werden konnte
- technischer knackpunkt war der Aufruf der Zugriffsfunktionen
- Einleitung erwähnen
- größte Herausforderung: die hohe dynamik des systems
- Beispiel
- Anpassungen auf an das Framework
- nicht für alles gibt es properties, aber die property getter und setter
- eigentlich reicht ein event aus
- es können auch eventnamen angegeben werden
- müssen allerdings data events sein
Dies war die Basis für die Controller. Diese wollen wir uns jetzt genauer ansehen.
Noch einmal zur Erinnerung. Die Controller befinden sich zwischen model und view und sind für die synchronisation der beiden zuständig.
- Davor:zusammenhang mit views
- Auflistung der verschiedensten Views
- Auf jedes kurz eingehen
- Jede hat bestimmte spezielle eigenschaften
--> je view typ ein controller
Object: verwaltet Felder mit einzelwerten wie z.b. textfeld, spinner usw.
List: Alle listenartigen Widgets
Tree: das tree widget
Table: Die tabelle
- Tabelle nicht umgesetzt
- neue Tabelle in der Planung
- Später natürlich angebunden
- Alle weiteren Beschreibungen ohne den object controller
- bequeme Zwischenschicht für das Single Value Binding
Zwei der in der Analyse herausgearbeiteten Features will ich jetzt mal genauer betrachten. Dabei handelt es sich um die Selektion und die Filterung. Diese wurden beide auf der Ebene der Controller eingebaut.
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- Selektion ohne das Data Binding
- Beispiel: Liste
- Selektion --> ListItem
- anhand dieses Widgets selektion bestimmen
- Selektion mit Data Binding
- immer Modelobjekte stellvertretend für die Listeneinträge
- genau diese werden auch bei der Selektion zurückgeliefert
- zwei Tatsachen:
1. Selektion ist ein array
--> kann wieder an eine Liste gebunden werden
2. Man ist völlig abstrakt von den Widgets
--> Selektion auf dem Baum liefert auch ein Modelobjekt zurück
- zuerst einige verschiedene Ansätze
- Letztendlich ist es im controller durch index-mapping
- So kann auch die Sortierung einfach umgesetzt werden
- Größtes Problem: binden nur von label und icon
- benötigte Werte werden in properties gespeichert
=> Erweiterung benötigt
- Delegate Pattern bietet die Möglichkeiten
- Ursprünglich aus dem bekannten Design Pattern Buch
- private klasse übernimmt teile der Funktionalität
- methoden-wrapper für bestimmte funktionen
- anders in qooxdoo
- Ansatz ist von cocoa bekannt
- delegate wird von aussen gesetzt
- jede Methode ist optional
- es gibt daher immer eine Standardverhalten
=> So kann code in den controller gebracht werden
- Sieht folgendermassen aus
- Delegate ist einfaches Objekt
- könnte auch qooxdoo object sein (this.methodenname dann)
- funktion wird dem controller übergeben (bindItem)
- In dieser Funktion wird dem controller gesagt, welche properties er wie binden soll
- Geschichte zum Zitat erzählen
Bestimmt hat sich der eine oder andere schon die Frage gestellt, wie die Models denn nun genau aussehen.
Dies zeige ich jetzt. Hier noch einmal das Bild. Das Model ist, wie schon zu Beginn erwähnt, für die Haltung der Daten verantwortlich.
- Da die daten in Properties sollen bieten sich einfache qooxdoo Klassen an
- Durch die change Events kann man so alle Änderungen mitbekommen
- Probleme mit Arrays
- Änderungen im Array --> bekommt man nicht mit
=> spezielle Array implementierung benötigt
- Aber nicht so spannend. Bei jeder Änderung gibt es einen Event.
Mit dem Models sind wir somit auch schon durch. Nicht gerade viel aber sie spielen in diesem Kapitel noch eine Rolle.
Denn es ist hier noch einmal dargestellt, dass der Store für die Datenbeschaffung und das schreiben in das Model verantwortlich ist.
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Daten Laden = Welches Format?
- Viele Denkbar
- Hauptformat ist JSON
- Diagramm sollte bekannt sein
- Delegate Pattern
- Was machen die zwei teile?
- Store: Laden und bereitstellen
- Marshaler: Generieren von Klassen und Instanzen
- Erstellen von Klassen zur Laufzeit?
- Wie werden Klassen in qooxdoo erstellt?
- Hier der Code zu sehen
- Gleiche bei der Definition der Klasse
- Kann auch ersetzt werden
- Spätestens jetzt sieht man klar, dass nur noch eine Funktion übrig ist
- Diese kann auch zur Laufzeit ausgeführt werden.
- Genau auf diese Weise werden die Klassen generiert
- Übriger Parameter: Name und namespace der klasse
- Wie benennt man denn die erzeugten Klassen?
- Feststellen, was sie unterscheidet
- Aufgabe
- Halten von Daten in Properties
- Properties sind nur leere Datenfelder ohne Typ
--> nur der Namen unterscheidet die Klassen
- Hash-Algorithmus benötigt
- Erste Idee: Konkatenieren der Property-Namen
--> Geht nicht wegen der Reihenfolge
- Hash-Algorithmus benötigt
- Erste Idee: Konkatenieren der Property-Namen
--> Geht nicht wegen der Reihenfolge
- Hash-Algorithmus benötigt
- Erste Idee: Konkatenieren der Property-Namen
--> Geht nicht wegen der Reihenfolge
- Lösung: Sortieren
- Nächstes Problem
- nicht eindeutig zuweisbar
- Lösung: Sortieren
- Nächstes Problem
- nicht eindeutig zuweisbar
- Lösung: Sortieren
- Nächstes Problem
- nicht eindeutig zuweisbar
- Lösung: Trennzeichen benötigt
- Welches?
- Beispiel mit $
- Geht auch schief
- Lösung: Trennzeichen benötigt
- Welches?
- Beispiel mit $
- Geht auch schief
- Lösung: Trennzeichen benötigt
- Welches?
- Beispiel mit $
- Geht auch schief
- nächster Versuch
--> Blick in die JSON Spec
- Was ist in JSON nicht ok aber in JavaScript
- einzig mögliches Zeichen sind die quotes
--> Jetzt geht es immer
- nächster Versuch
--> Blick in die JSON Spec
- Was ist in JSON nicht ok aber in JavaScript
- einzig mögliches Zeichen sind die quotes
--> Jetzt geht es immer
- nicht nur der reine JSON Store wurde umgesetzt
- Proof of concept
- twitter vie REST angebunden, Rückgabeformat JSON
- Beispielapplikation mit Gears gebaut
- flickr angebunden (auch JSON)
Jetzt haben wir alle Teile im einzelnen gesehen.
Ich hoffe mal es hat jeder einigermaßen verstanden, welcher Teil was macht. Um dies zu verdeutlichen, habe ich noch zwei Beispiele aufbereitet, die dasd Zusammenspiel verdeutlichen.
- Erstes Beispiel: Laden dieser JSON Datei und anzeigen in einer Liste
- Daten entsprechen keinem vordefinierten Format
- Könnten auch Objekte in dem Array sein
- Code auf der folgenden Seite würde aber anders aussehen
1. Liste erzeugen und anzeigen
- hat noch gar nix mit data binding zu tun
2. controller erzeugen.
- kein Model gesetzt
- direkt mit der liste verbunden
3. Store erzeugen
- kennt die URL
4. Zusammenbinden vie Single Value Binding von Store und Controller
- Kein Model gesehen
- Wo ist das aber?
- Sehen wir gleich.
- Zuerst: Ergebnis
- Einfach und nichts besonderes
- Aber nur 5 Zeilen code!
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt
- Zurück zum verlorenen Model
- Ablauf zeigt noch mal den Zeitlichen ablauft des Codes
1. Daten sind schon da
2. Liste wird erzeugt
3. Controller wird erzeugt.
- kennt die liste
- model ist null
4. Store wird erzeugt
- kennt die daten
- model ist null
- beginnt mit dem laden
5. binding der model properties wird erstellt
- Code fertig
6. Asynchron kommen die Daten an
- Model wird mit dem Daten erstellt