Implement support for computed properties (instead of marshalling)

mikermcneil commented 12 years ago

See http://kilon.org/blog/2012/02/backbone-calculated-fields/

mikermcneil commented 12 years ago

Schema Mapping / Marshaling / Serialization

In the same way that the goal of the APIService or server-side JSON views is to convert the raw database schema to the outward facing API format (and vice versa), the primary goal of virtual fields is converting from the server-sent API schema to the UI state model (and vice versa).

The primary goal of bindings is to convert a state change in the client-side model to the proper elements in the DOM, and to convert

Virtual fields

Getter: Allow Model.get() calls to an artificial attribute (which actually runs a function). Use case: empty virtual field is based off of num_children, an actual field. A call to the virtual field getter for a UI switch might return the present value of the notificationsEnabled attribute.
Setter: Allow Model.set() calls to an artificial attribute (which actually runs a function). Use case: Setting the year, month, or day virtual fields actual changes the scheduledDate attribute. Changing the state of a switch triggers the appropriate change to the UI-agnostic state in the model.

Bindings

The analog at the view layer is bindings: -Getter: Example: Getting the username actually selects the username input form field from the DOM and grabs its value to offer up as a client-only piece of state -Setter: Example: Setting the padding actually looks at the depth of the file/directory and adjusts the left padding accordingly. Setting empty removes or adds the collapse/expand arrow as necessary.

Summary

Server -> Getter <- Virtual field
- Given a virtual field name, translate raw db or API data into something usable in the UI. DOESNT INTERACT WITH DOM.
Server -> Setter <- Virtual field
- Given a virtual field name and new value, also update other affected fields which may not be directly bound to the UI (i.e. convert emailNotificationsToggleSwitch into notifications.email (convert UI schema into raw db or API schema). DOESNT INTERACT W/ DOM.
DOM -> Getter <- Binding
- Given a binding attribute name, return a value generated by selecting from the DOM.
DOM -> Setter <- Binding
- Given a binding attribute name and the new value, update the DOM to reflect the change.

Data flow

Shared, Persistent Database Schema <-----> UI-Agnostic Transport Schema (REST) <-----> UI-Specific Presentation Schema

Example

UPDATE NotificationSetting SET email=TRUE WHERE AccountId=7; <-----> NotificationSetting.findAndUpdate({where:{AccountId: 7}}, {email: true}); <-----> { id: 7 notificationsEnabled: true } <----->

``` UINotificationSwitch.model.attributes.notificationsEnabled virtualField set: UINotificationSwitch.set('notificationSwitchOn') virtualField get: UINotificationSwitch.get('notificationSwitchOn') <----->

binding get: return $(".notification-switch").val() binding set: $(".notification-switch").val(this.notificationsSwitchOn) <input type='checkbox' class='notification-switch' selected='selected' />

mikermcneil commented 12 years ago

@ghernandez345 The getters UI model bindings ties into what you're working on (specifically getting the value of DOM form/input elements and stuffing them in the model)

Thoughts, feedback?

mikermcneil commented 12 years ago

State transfer encoding:

DOM
Bindings
<------- Virtual fields, subscriptions
-------> Backbone.sync

<------- APIService and/or JSON views
-------> Parameter preprocessor and error checker 
ORM interface (MATE)
DB

SQL --> MATE ---------> APIService or JSON views ---------> <---------- Virtual fields <----------- Bindings <--- DOM

APIs

       DAO  ----->  MongoAPI   ---------------------------->   REST API    <-------------  Backbone.Model  <----- jQuery

mikermcneil commented 11 years ago

Computed attributes would be nice to have-- most of the other things can be ignored

balderdashy / mast