|
|
@@ -46,28 +46,30 @@ the _Model_ just observe and manipulate contents of the _ViewModel_.
|
|
|
|
|
|
More precisely:
|
|
|
|
|
|
-1. You provide the class for _ViewModel_ data (`AppModel` in the examples).
|
|
|
-You can build it any way you wish, it has to be able to hold all the data
|
|
|
-_ViewModel_ may need to hold. It can also hold some methods for manipulation
|
|
|
-of these data, which is good for the example, but in real project
|
|
|
-this should be the responsibility of _Model_.
|
|
|
-1. You create the class for _ViewModel_ itself (`App` in the examples).
|
|
|
-This is more or less mechanical task - just create subclass of right
|
|
|
-base class and fill in `initialize` method appropriately, so that
|
|
|
-it wraps the real data (instance of the class from previous paragraph).
|
|
|
-This wrapper class implement the _blackboard_ pattern -
|
|
|
-in which many external observers (called specialists)
|
|
|
-observe the data object (called blackboard),
|
|
|
+1. You provide the class for _ViewModel_ (`TrappedCounter` / `TrappedTodo`
|
|
|
+in the examples). You can build it any way you wish, it has to be able to hold
|
|
|
+all the data _ViewModel_ may need to hold. It can also hold some methods
|
|
|
+for manipulation of these data, which is good for the example, but
|
|
|
+in real project this should be the responsibility of _Model_.
|
|
|
+1. In `initialize`, you should register an `Axon` into _ViewModel_ instance.
|
|
|
+It implements the _blackboard_ pattern - in which many external observers
|
|
|
+(called specialists) observe the data object (called blackboard),
|
|
|
make partial changes and react to them. Elements of _View_
|
|
|
are observers of the _ViewModel_ blackboard, as should
|
|
|
be the parts of the _Model_ (this way, _Model_ and _View_
|
|
|
are completely decoupled and both see only changes
|
|
|
to the blackboard, that is, the _ViewModel_).
|
|
|
+In Todo example, one trivial specialist is created as well,
|
|
|
+which observes for changes in todos and updates their remaining number.
|
|
|
+In real world, it should be in _Model_ with other specialists.
|
|
|
1. You write HTML and annotate the elements
|
|
|
with the data-binding expressions (attribute `data-trap`)
|
|
|
in which you describe what data to bind to (_path_)
|
|
|
and how to process it in the way to the user or from the user
|
|
|
(_processors_).
|
|
|
+1. Since you will likely use some non-trivial processors in HTML,
|
|
|
+(or in code via API which is also possible), your app package
|
|
|
+should import 'trapped/Trapped-Processors'.
|
|
|
1. When initializing the page, you must call `Trapped start: anArray`
|
|
|
where _anArray_ should contain instances of all blackboards (most often
|
|
|
you will only have one, `blackboard` in the examples)
|
|
|
@@ -272,7 +274,7 @@ are instances of some subclass of `TrappedProcessor`.
|
|
|
|
|
|
Basic processor _contents_ which is used as a default
|
|
|
when no processing chain is specified, is contained within
|
|
|
-`Trapped-Frontend` package; all the other processors supplied
|
|
|
+`Trapped` package; all the other processors supplied
|
|
|
by Trapped which will be described later, are contained
|
|
|
in `Trapped-Processors` package. If you look at the factory
|
|
|
(`TrappedProcessor class`), you see that their factory methods
|
