superfeedr/indexeddb-backbonejs-adapter

Optionally override Backbone.sync

weblivz opened this issue · 6 comments

Backbone allows you to set the persistence provider on a per model basis.

As fas as i can see, this provider overwrites the global Backbone.sync method. Be neat to make this optional ... or give is another name so that we can use the Backbone default ... by default .... and override on a per model basis. eg

var aModel = Backbone.Model.extend({
sync: IndexedDB
});

+1 for this. In one application some backbone models should be persisted in IndexedDB, some will use XHR etc.

Hum. This should be part of Backbone, right? not part of this adapter, should it?

I didn't see that such case was solved by backbone.

I saw here two possible solutions:

  1. Adapter provides function (that one which overrides Backbone.sync) and not overrides global Backbone.sync. If somebody need model that should be persisted to IndexedDb he overrides sync for that particular model(like in the first comment of this issue). The problem here is to pickup good name for that function.
  2. You create some class Backbone.IndexedDbMode which override sync method.

So Backbone already provides two methods for dealing with such cases. I think that you should handle this case inside this adapter. What is your opinion?

P.S. Maybe there are other variants to solving this problem.

I am sorry I have so little time these days. Maybe you could fork and send a pull request so I can look at all this?
Thanks!

I'm pretty new to backbone and this extension, but for what I'm planning, I think this will be an issue for me as well.

I'm working on an offline application (using html5's application cache and indexedDB) that allows data to be saved to the client, manipulated, and then pushed back to the server at a later time.

So for this project, it would make a lot of sense if a single Backbone object could sync to both the server and to indexedDB.

From what I've gathered so far it seems that this extension completely overrides how backbone persists data and doesn't really give the developer the option to switch between them.

At a minimum I would probably need what @weblivz has proposed, but that would still leave me with the need for two models, one facing indexedDB, the other facing the server. That would be less than ideal, but manageable.

Thoughts?

@crankharder 2 models? Not sure it's a good idea..; I believe you could certainly create a wrapper around this IndexedDB adapter that would be in charge of persisting either locally or to the server, as well as the sync logic when needed.