jWidget philosophy

Model and view

1. All main application classes and interfaces are classified to model and view.
2. Model stores data. All data is stored in a model.
3. Model may initialize internal data bindings. To control their life time, the model should inherit Class and own the bindings.
4. View classes (components) render data to the screen. All components should be inherited from Component.
5. View has direct references to the corresponding models. On user action, component calls the corresponding method of the model in order to modify it.
6. Model doesn't have direct references to any views, but it dispatches messages about its modification.
7. View listens model modification messages to do necessary updates.
8. View should initialize and aggregate data bindings provided by the library.

Object life time control

1. You should destroy the following objects:
   • Bindings that have shorter life time than their source properties/collections.
   • Any objects that may initialize such bindings or other such objects (recursively).
2. An object that issued a binding/object creation is responsible for its destruction.
3. It is optimal to destroy objects using aggregation mechanism implemented with own method, or using internal features of classes:
   • Method IProperty.ownValue
   • Method IBindableArray.ownValues
   • Method IBindableMap.ownValues
   • Method IBindableSet.ownValues
   • Config options Mapper.destroy, AbstractMapper.destroy etc.
4. Sometimes it is acceptable to destroy objects explicitly using destroy method.

Data binding

1. Objects and DOM-elements should never be recreated without a strong reason. Instead, they must be updated using data binding.
2. Data binding of single values is performed with Property class and its bindings.

Data binding in collections

1. Data and components are structured based on three collection types: BindableArray, BindableMap and BindableSet. Read the common theory of algorithms and data structures to learn pros and cons of each collection type.
2. Each collection dispatches messages about its modification.
3. You don't have to listen all collection messages manually. Instead, you should use standard collection bindings. The bindings provide a simple way to connect collections to each other.
4. Collections are enclosed inside binding methods. In other words, any modification of a collection triggers at most one modification of another collection, which is connected to the first one using a standard binding.
5. Almost any user action can be handled with a single manual collection modification in the model. All other collections (including component collections in the view) must be synchronized automatically via bindings.
6. For proper and fast application running, it is enough to configure all bindings only once, similarly to how you used to configure indexes and foreign keys in SQL data bases.