v0.4.0

List View naming convention change to Item View

A major List View naming convention change happened. The wording of child view means a view that any view (including a list view) might own. List Views always had the ability to both own auto-generated views and other classical child views. However, due to treating these types of views as the same, inconsistencies in logic occured (e.g. this.hasChildViews() while checking if there were any autogenerated views). Therefore, a new name was needed to differentiate the auto-generated child views of a list view and other child views it might have. "Item View" was used. Like a Perspective View, there is nothing particularly special about this type of view but more a label given to help understand it's role and lifecycle.

Thus, some arguments, fields, and methods in the list view were updated including:

Fields / Initialization Arguments:

NOTE: using the deprecated names as arguments during initialization will still work, however references to them afterwards (e.g. listView.childView) will no longer exist but rather only referenced as there new names (e.g. listView.itemView)

• childView -> itemView (the view class of the auto-generated views)
• childContainer -> itemContainer (the injection site of the auto-generated views while using a template)
• childContext -> itemContext (the object or function result that's passed to the item view's during initialization under the name "context")
• childModel -> modelName (the argument name of the model when initializing an item view, defaults to 'model')

Methods:

• getChildViewFromModel -> getItemViewFromModel (getting an item view that corresponds to a model)
• any private methods (prefixed by "__") containing the words "child" were updated to use "item". __createChildViews, __createChildView, __removeStaleChildViews, __emptyAndRebuildChildViewsFragment, __generateChildArgs

Note: aliases were provided for backwards compatibility for the following methods. These methods are now deprecated in favor of their "item" equivalents:

• getChildViewFromModel
• __generateChildArgs

Collection reset and sort optimizations

Collection reset

A collection reset effectively forced a re-render in order to make sure all item views were placed correctly on the DOM. This meant detaching, rendering, and attaching all the item views. In 0.4.0, the view will inspect the models removed and added as part of the reset. If the number of additions and deletions is half of the number of new models that would have to be rendered, the list view will add/remove these item views individually, instead of invoking a re-render. This threshold can be changed by setting:

this.updateThreshold

NOTE: because the calculation puts the sum of the additions and removals over the resulting size that it would render, the threshold value can be greater than one. If you would like to always update using adding/removing instead of re-rendering, make the threshold value Number.MAX_VALUE

Collection sort

During a sort, the elements were always rearranged even if the order never changed. Now, in 0.4.0, the list view can identify if the order hasn't changed, and not manipulate DOM.

v0.3.2

1. View state now uses NestedCell instead of Cell for enhanced change event triggering.
2. ListView - sort doesn't call a full, expensive re-render but instead reorders elements on the page
3. Bug fixes on ListView - added missing var for strictness.
4. Bug fixes on ListView - fixed removal of events from old collection when adding a new collection.
5. Tests now run via Travis-ci! (but timing tests fail).

v0.3.1

1. List views now respect the __modelId attribute when creating child view.
2. Moved all initialize methods to constructors for FormModel, FormView and ListView (the others were already setup to not have initialize methods).
3. ListView.addChildView() now activates/attaches new child views.
4. Collection.reset now removes unwanted child views from ListView.

v0.3.0

1. Allowed "childView" field/argument on a list view to be a function. If it is set to be a function, then for each model, it will invoke this function while passing in the model in order to determine the type of child view that will be generated
2. #111 Allowed FormModel's to save without tracking any models if it has its own url
3. #112 Fixing problem with url field on FormModel not to be seen by save logic
4. #109 Cache collections that aren't tracking any ids, will correctly fall back to previous fetch logic
5. #125 addModelAndTrack now adds the model to the parent cache collection as well
6. #141 ListView now treats child views very similarly to normal child views. All the child view lifecycles should be respected including, activate, rendering, detach/attach, etc. NOTE: this means that child views are rendered whenever the parent is re-rendered (including collection sorts and resets). This means that there is a potential performance hit. Please let us know if this has affected you.
7. #121 because the lifecycles of list view's child views are fixed, child views are now rendered when attached
8. #144 updating to backbone version 1.2.3. Please see http://backbonejs.org/#changelog if this affects you
9. #118 added view.get('foo') and view.set('foo') as aliases to view.viewState.get('foo') and view.viewState.set('foo')
10. #140 added keywords to package.json

v0.2.2

1. Added an addCollection() method to ListView so that you can register a collection (setup listeners) after the view is constructed.
2. Updated the UMD declaration for handlebarsUtils so that it can be included and used correctly in a build using CommonJs imports.

v0.1.15

• Added the concept of Shared views who's overall lifecycle (i.e. construct and destroy) are outside the parent view. Shared views are not destroyed when the parent is destroyed. In contrast to Child views which are destroyed. This is the only difference between Shared and Child views.
• Updated the collection property from _collection to collection on ListView to align with backbone's collection field.

v0.1.15

See release notes for v0.1.15

v0.2.1

Fixing logic and recursiveness of _attached and _detached

v0.2.0

To see changes:
v0.1.7...49f4e97

Issues resolved in 0.2.0:
#3, #5, #39, #42, #47, #61, #62, #63, #64, #66, #67, #68, #71, #72, #73, #75, #76, #77, #102, #103, #104

1. Updates to README.md
2. Created DOCUMENATION.md to give a lengthy explanation of the major topics and most modules
3. Adding modules got easier, because updates to bundle.js no longer require understanding the order of dependencies. Instead, if a module depends on your module, name your module as a dependency under the "dependencies" variable in bundle.js. Likewise, if your module depends on another, add an entry to "dependencies" and list your module's dependencies. NOTE: it will look in the /modules directory for any modules, so standalone modules require no additional configuration.
4. All internal variable and method names used by Torso should be prefixed with double underscore: "__". Any references to Torso internal methods (most often they were already prefixed by a single underscore: "_") should be updated. Variables and methods that are part of the public API, will contain no prefix.
5. FormModel's can now contain a "url" field. This allows for multi-model, transactional saving. See #5 for more details on the implementation/API.
6. View.js and FormView.js now default to add "model" and "view" as part of the context created by prepare(). If you override prepare() method, you will have to add these back. They contain this.model.toJSON() if one exists, and this.viewState().toJSON() respectively.
7. The feedback mechanism was refactored out of FormView and put into View. All views should now have feedback available to them.
8. A View's feedbackModel was changed to feedbackCell. Any reference to feedbackModel should be updated to be feedbackCell
9. ListView's getChildView method name was changed to getChildViewFromModel. References need to be updated.
10. All Torso implementation to set up a View was moved to Backbone's constructor option. This means that when extending a View, there is no need to invoke Torso.View's initialize method or a super method. However, any further extensions, should still invoke their parents initialize method.
11. All mentions to super were removed from View and Collection. Either this logic has been already handled (as in the case of View and Collection) before initialize is invoked or a direct invocation of the parent's method are needed (as with FormView, ListView, and other specific extensions of the base classes).
12. A View now comes with a viewState field that can keep track of important data associated with the view's state. This is convenient when you want to utilize a cell's ability to trigger or react to events. Also, by default, viewState is available in your template because the prepare() method's adds it to the context.
13. this.render() is not invoked automatically when a view is instantiated. Instead it is invoked on attach(), when the view is about to be attached to the DOM.
14. By default, a view is "activated" when instantiated.
15. The introduction of a view lifecycle was introduced. Initialize/dispose, activate/deactivate, attach/detach are now part of the life of a view. Callbacks were introduced (_activate, _deactivate, _dispose) for adding custom logic when these states are reached. For more details, look for the "View" section of the https://github.com/vecnatechnologies/backbone-torso/blob/master/docs/DOCUMENTATION.md
16. View's render now defaults to invoke plug and unplug
17. Collection mixins were slightly simplified to be pure Backbone extensions rather than complicated mixins. This may cause issues if you were relying on Backbone's parent field.
18. Collection's fetch now returns a promise. (Both cache and requester)
19. Collection added addModelAndTrack and trackNewId which are convenience methods to help add/track a single id.
20. Fetch from a cache collection will either make a GET request to the base collection url, or if fetchUsingTrackedIds: true was passed as an option during construction, it will only fetch the ids it is currently tracking.
21. A cache collection can now change the HTTP action performed during a fetchByIds using the option fetchHttpAction.
22. A configure module was added, that when required simplifies configuring Torso. See #39 for more details.
23. guidManager was removed. Please remove all references of this module
24. handlebarsUtils no longer makes an explicit dependency on Handlebars. Instead the module returns a function that when invoked with Handlebars passed in as the only argument, Torso's handlebars helpers are added.
25. Some bug fixes to templateRenderer
26. Handlebars is now not a dependency of Torso
27. Test cases were added for collections.
28. Test cases were added for FormModel transactional saving
29. Added isAttached() to view. This returns true if the view is attached to the DOM.
30. Added _attached and _detached callbacks that fire on the view and its children when the the view is attached or detached from the DOM.

Upgrade notes from 0.1.x to 0.2.x:

• ListView had a bunch of properties' name change from _ to (view._collection -> view.collection).
• View.super() is no longer a thing.
• TorsoView.initialize is empty (moved logic to constructor).
• Views are no longer rendered on creation (but attaching calls render anyway).
• Torso Handlebar helpers need to be setup explicitly in each app.
• cleanupSelf() is no longer a thing. Override _dispose() and you don't have to worry about the super's dispose logic.
• Activate, detach, attach, deactivate, dispose should use their _ counterparts and should be rarely overridden.
• Default prepare now has 2 properties { model: model.toJSON(), view: viewState.toJSON() } - some templates needed to be updated.

v0.1.12

Prepare 0.1.12 release for npm