Anyways using sync method only in collection or only in model can suffice, then why do they have to sync at both the places?
Actually both sync() methods are just proxies to a common Backbone.sync() method:
Model.sync()
Collection.sync()
Backbone.sync()
Collection always delegate in the Model.sync() for individual operations over its individual models like: create, remove and so on. But Collection uses its own sync() in the fetch() operation due it is very different to fetch a Model or a Collection, for example: the URL follows another patter and the backend layer should respond different.
In the other hand I see the Backbone.sync() as a private method and I try to not use it directly, if I'm doing this I don't feel well. I think the sync() method is a handler point to allow you to overwrite completely the backend synchronization a method that you can overwrite to implement different persistance layers as for example using LocalStorage. But not for be called directly.
As #JMM has said in the comments, the Model.sync() and Collection.sync() is also a good point to be overwrote to make it "does something custom and then calls Backbone.sync() to carry on as usual".
Backbone doesn't have a sync -method in models and collections by default, but both models and the collections have methods (fetch for both models and collections and save, destroy for models) that use the Backbone.sync -method to make ajax-calls. Docs, annotated source
The methods that use Backbone.sync check for the existence of a sync method for the individual collection or model, so the default functionality of sync can be overwritten for everything by overwriting the Backbone.sync or for specific parts by extending a model or collection that needs custom sync with a sync -function.
As to why both models and collections have the capability to synchronize with the server: flexibility. If only collections would have the syncing capability, then you couldn't have individual models, and if only models would have syncing capability, how would you fetch large batches of models initially from the server. There is no downside in having syncing capabilities for models and collections, so why not?
My counter-question for you: How would having sync on only the other suffice?
Related
I've created a class named JsData and instantiated it in App.xaml.cs so that I can access it from multiple viewmodels. The JsData has several ObservableCollections, some properties for configuration and some methods which manipulate the process of automatically pulling data from remote server.
Now comes the question. Is it convenient for me to bind the global data to my views with minimum coding? Besides, I'm using Caliburn.Micro. Is it doable and appropriate to notify PropertyChanged events to viewmodels using messaging?
I think the best way to do this is to create a service that your view models can implement. That way on,y the view models that need the data can implement the service, and the service is more flexible because it can be injected in the view model construction. This keep your view models more decoupled and honors the mvvm pattern.
I would not use messaging to not notify changes, that would create unnecessary overhead. You just need to have your view model implement inotifypropertychanged and then get the service in your constructor And then pass the service values to properties in your view model that raise the property changed event.
If your need help defining a service just let me know and I will post a sample
I am developing an application in which there are two views.
View 1 is a list of documents, presenting some vital details
View 2 is the document it's self. Editable.
The application is multi-user. So the app polls the server for updates to the collection.
The problem is that when collection (view 1) is refreshed (.fetch) it unbinds all events from the child models. Including the one open in view 2. Where as before the fetch, any changes in the document (model) were reflected in the list (collection), after the fetch the document (now old model) is now unrelated to the list (collection).
After looking at the backbone.js source, this is the intended behavior. Is there a work around solution to this?
Yes, this is a very common issue. The Collection is reseted and all its references refreshed, even if they target the same Models than before.
I think could be nice idea to implement a Collection.update() method in opposition of Collection.fetch().
Check this tread for approaches to deal with this behavior: Backbone.js collection upsert?
Is it possible to talk to a cometd service when using Backone.sync?
Thanks in advance
EDIT
After some reading it seems you can overwrite the Backbone.sync().
Backbone.sync is the function that Backbone calls every time it attempts to read or save a model to the server. By default, it uses (jQuery/Zepto).ajax to make a RESTful JSON request. You can override it in order to use a different persistence strategy, such as WebSockets, XML transport, or Local Storage.
I can't find any more information on this though.
Indeed, all you need to do is override sync.
A good example to follow in order to see how it is done is the backbone localstorage storage.
In brief, you define a method that replaces sync on your models/collections:
mySync = function(method, model, options)
The method argument can be one of read, create, update, delete and model can be either a model, or a collection. Essentially you only need to cover the four methods and everything will work like a charm. Bear in mind that while the localstorage example is useful it is also simplistic in some ways, so having a look at Backbone itself never hurts.
I'm using backbone js with an xml api data feed. I have a top-level model for each page that receives the xml and converts it into json. I then have additional methods in the model that return specific parts of the json model to the specific views through a controller. This is all working as expected.
I would like to periodically (via setTimeout) update the top-level model and have it fire the change event and update the views. My question is where I should handle/initialize the firing of this periodic event to update the model since it's not really a user trigger event?
I'd give my model a startUpdate() method, an endUpdate() method, and an internal onTimerUpdate() method that did a fetch. You can then call, on the model, the startUpdate() and let it run as needed, pausing it when it would be inconvenient for a server-side update to run (say, in the middle of a customer manipulation of the data), and restarting it after a client-side change had successfully completed a write to the server.
Better yet, you could make it a mixin and use it with a number of different models.
Am using a view file,controller and a helper. am accessing data value through webserver.
Steps:
the controller get value from webserver and set it in the view. the view uses the helper to display the data in some format. But my helper again calls the webserver method to get the inner values. Is it correct the helper accessing webservice method? Is it the correct way of programming in mvc?
Thanks,
IMO, a webservice is just another datasource and should be accessed via the model. If it's me, I handle it by either creating a new model for the service call (if the service call is in support of an existing entity, it may make more sense to make the call in that entity's model itself). My controller calls the model method, sends the data to my view which, in turn, forwards that data on to the helper.
This maintains the MVC separation, but still allows the data you need to make it's way into the helper where you need it.
I will tell you what is written in the Ruby on Rails book. I can not remember the title right now but...
Helpers are usually used for view rendering not for server calls.
Hope it helps.