jWidget philosophy

Model and view

1. All main application classes and interfaces are classified to model and view.
2. Model stores the data. All data is stored in 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 corresponding models. On user action, component calls corresponding method of model in order to modify it.
6. Model doesn't have direct references to any views, but it triggers events about its modification.
7. View listens model events to make neccessary updates.
8. View should initialize and aggregate data bindings provided by the framework.

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 the objects using aggregation mechanism implemented by method own, or using the internal features of the classes:
   • Method IProperty.ownValue
   • Method ICollection.ownItems
   • Config options Mapper.destroy, AbstractMapper.destroy etc.
4. Sometimes it is acceptable to destroy the objects explicitly using method destroy.

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: List, Map and Set. Read common theory of algorithms and data structures to learn pros and cons of each collection type.
2. Each collection triggers events about its modification.
3. You don't need to listen all collection events manually. Instead, you should use standard collection bindings. The bindings provide a simple way to connect collections to each other.
4. Collections are closed inside binding methods. In other words, any modification of one collection triggers at most one modification of another collection, which is connected to the first one using standard binding.
5. Almost any user action can be handled by a single manual collection modification in 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 indexes and foreign keys configuration in data bases.