I am new to backbonejs and I cannot find answer to my query in backbone docs.
I'd like to create CollectionView and use as part of other view without collection and wondering if its possible.
Short answer is No
Standard Collection View work flow:
Collection view iterate over collection. On every iteration instancing new ModelView and provide iteration model as data and delegate render to ModelView instance. ModelView instance render data and keeps template.
So u have to keep collection to iterate with of replace it with something else to iterate with.
Related
Im currently learning about the MVVM pattern in WPF. I think it is really cool but my question is: is it correct to use the viewmodel directly for appending children to its view?
For example lets assume we had a method which contains a loop which adds new rows to a grid when a button is clicked. Should my ViewModel only contain pure data or can it also contain logic for placing new elements on the field? As well as removing them.
is it correct to use the viewmodel directly for appending children to its view?
No. The view model shouldn't know about any view elements.
Should my ViewModel only contain pure data or can it also contain logic for placing new elements on the field? As well as removing them.
The former. The view model may expose a collection of data objects that the view happens to display in a Grid. Or some other kind of panel. The view model doesn't care about which.
You would typically use an ItemsControl in the view to display the items in a view model collection, i.e. the ItemsControl binds to the source collection and displays a visual representation of each item in a panel.
For my setup I have two sub-views (on the same View) that render the same type of Models, however each view uses a totally different set of Model (one displays the latest ones, the other is split in 4 subviews per category). Using filter() on a Collection doesn't work because I need 4 posts per Category and about 20 new ones.
Since they are both on the same page, when I update the model on one view, I want the same model to be updated on the second view.
I tried a couple of things:
Use one Collection on the mainView, fetch inside the mainView and give this common Collection to the subViews. This is working as long as both subViews are using the same set of Models, which I am not.
Use custom events and a Collection in each subView. When Model is updated, send a global Backbone.trigger with the modified Model, catch it on the other side and do stuff as needed. This is also working but the implementation is really not pretty or efficient. Having all the Models listen for change and only act if their id is the correct one seems counter productive.
Use one Collection on the mainView and one per subView, the idea being that the Collection on the mainView holds all the items and distribute them to each subView's Collection as needed. This works but fetching the data, duplicating in the main Collection and the other subView Collection is kind of a pain and requires me to hold an instance on mainView inside each subView, which I don't really want to do because each subView is a "component" and can be use in multiple places.
People online seem to do the Events way most of the time, but I wonder if someone has a better idea.
Thanks a lot.
I have a backbone collection that is dependent on another collection in my Rails application. I want to make sure that the view that displays the dependent collection is emptied out and the dependent collections is 'reset' it its view as well as corresponding records from the server are deleted. Is there an easy way to do so or do I have to loop through the collection and fire off model.destroy calls for all models in the dependent collection when the last record from the existing collection is removed?
Backbone Collections have a reset() (docs) method that will take a list of models as an argument. If you pass no argument, it will empty the entire Collection. However, this will not by default remove the models themselves from the server as you probably saw.
There's also a sync() (docs) on the Collection that will sync the collection (or all the models in the collection) to the server. Of course if you've run reset() the Collection is now empty, so that doesn't really help.
In the end I think that you will have to loop through the Collection to destroy each model (unless you want to take a serverside approach to limit your calls), but you should be able to extend your Collection and add a destroyCollection() method, or simply extend the already present reset collection to call the destroy() on the models before it resets the collection to empty.
If this doesn't help maybe provide a higher up example of what you're trying to achieve and maybe there's an even simpler way?
I have a main collection of models that I then filter into 3 separate collections (Think categorized menu). I have a timer to do a fetch on my main collection to make sure it is in sync. Each of my filtered collections is the basis for a Marionette CollectionView and renders properly the first time through. As soon as my main collection fetch is completed by the timer, each filtered collection refreshes with the main collection's data.
Update: My guess is, that since I am wrapping my filtered collection in a new Backbone.Collection, The reset is applying to each of my collections that share the same models, and so the fetch triggering the reset on my collection, actually triggers the reset on all my filtered collections as well, and then populates it with the full collection.
How do I get around this?
It seems to me that you are sharing certain objects by reference. If you would like to contain 3 isolated collections based on some original shared state, but without creating any relation to that state, I would copy all data and create new objects. This can be done via _.extend.
It is possible I may be misunderstanding your situation altogether. Some context/code would be helpful.
The issue was me. :)
I wasn't thinking, and I was creating new instances of the main collection type, even for my filtered collections. This was creating the timer on all the filtered collections too, and was, of course, refreshing the filtered collections with the main collection data.
Whilst implementing my first MVVM application in WPF, I've been wondering about the pros and cons of wrapping Model collections in related ViewModel collections to use in the View.
In our system we are likely to have several potentially large collections e.g. Order Lines in an Order, and Stock Items which could be selected for an Order Line. At present these are looked up from SQL in the Data Access layer, and then SqlDataReaders are looped around to create a collection of Model Objects.
To then loop around the collection of Model objects when creating a collection of ViewModel objects seems like an unnecessary overhead. When there are large collections of Model objects would it be better to expose these directly on the View?
Thanks in advance for your help, Mark
Edit
While reading up on this subject I found this MSDN article from July this year (reviewed by Josh Smith no less) which gives a pretty balanced view of MVVM, and in the 'Collections' section said this:
Another problem with collections is
determining when or if to wrap each
Model instance in the collection
within a ViewModel instance. For
smaller collections, the ViewModel may
expose a new observable collection and
copy everything in the underlying
Model collection into the ViewModel
observable collection, wrapping each
Model item in the collection in a
corresponding ViewModel instance as it
goes. The ViewModel might need to
listen for collection-changed events
to transmit user changes back to the
underlying Model.
However, for very large collections
that will be exposed in some form of
virtualizing panel, the easiest and
most pragmatic approach is just to
expose the Model objects directly.
Thanks very much for the comments so far, trying to limit the amount of data passed into the ViewModel, or using paginated or other suitable controls would reduce problems I'm sure, but I wonder if there would there still be situations where it would be better to simply bind to a collection of Model objects within the ViewModel?
I guess that it would really depend on how you want to go about displaying the data. Afterall the ViewModel is primarily there to handle the data that the View requires.
Assuming that your data layer provides you with just the data collections you could always restrict the creation of elements within the ViewModel depending on those that you actually want to see.
For example you may have a Datagrid to display Order Items for a given Order.
Thus you could have a ViewModel Property AllOrderItems bound to the datagrid and yet its getter is as follows:
public List<OrderItems> AllOrderItems
{
get{return this.DataAccessLayer.GetOrderItems().Where(x=>x.OrderNumber==this.OrderNumber).toList();
}
Here the DataAccessLayer is a class that holds cache database data and interfaces to the database. If kept as a singleton then data duplication within it will be reduced.
You can adapt your ViewModel to do as much or as little filtering of data from the DataAccessLayer as requried. The collections can be Observable if requried and the DataAccessLayer can generate events for VMs to react to for cases of new data being added, removed, saved to the database.