Please see this fiddle:
I'm trying to set a collection from a select multiple. Press "Show JSON" and you'll see the contents of thing.subthings.toJSON. Here I've put subthings as a variable on Thing, but is doesn't matter. No collection is updated by the multiple select.
I'm also showing the contents of the collectionObservable in the list below the select multiple.
OK. Will do. I'm working on 0.16.0 and will roll in a fix for this.
@mentat : Hi Jesse, I've looked at your jsfiddle (thank you for the great sample!) and see what you are trying to do...
kb.CollectionObservable was designed to be unidirectionally synced with a server and the models within the collection. What this means is that if you are doing long polling, etc on a server, the collection and then all of the view models stay in sync.
I can add bi-directional syncing, but I'm not sure what it "means" and hence how best to implement it. Can you help me make some decisions here?
1) if models are deselected, I suppose I can maintain a second array of removed models and add/remove them to the collection as the user makes selections. What does this mean for deleting models? (when would delete be sent to the server for deselected models?)
2) For sorting this array, I do not have access to the options "allObjects" collection. Do I need to save the original order and maintain a sorted array or can I just push newly selected items onto the end of the array?
3) if new models come in due to synchronization with a server, can I throw away all of the selections that are no longer in the collection? Do I need to maintain sorting as in 1) when the collection changes?
4) what do I do if the underlying collection is reset? Do I add everything to the observable array or should the list be intersected with the current selections?
I sort of wonder if this can be done outside of knockback since each person may have different needs for customizing the reverse synchronization.
Thank you for sharing your thoughts....
This is not about bi-directional syncing
here is fix
there is just no way to extract model from custom ViewModel. So I use that trick with storing model reference in viewmodel.
ahh sorry I have dumped viewmodel from collectionObservable - it has model reference in __kb.
hmm what is the problem to reset underlying collection with array of models?
I tried to make it without model reference - it does not work http://jsfiddle.net/Mw4FQ/50/
because collection keeps creating new ViewModels when i reset and that new are not the same as in options binding....
So for this to work inside collectionObservable you should reset underlying collection with extracted models but keep viemodels you have received...
@xdenser : thank you for the fix and your thoughts!
If you want to store a model in a custom view_model, you can use kb.utils.wrappedModel(vm, m) and kb.utils.wrappedModel(vm), setter and getter. The model is automatically added if derived from kbViewModel or created in a collection observable.
I'll look into the case with no model references. I would expect that kb.utils.wrappedModel(vm) would work to extract them. As for sharing view models between the options and selectedOptions, the library user would need to create a kb.Store and share it between the two collection observables by passing it in a collection observable constructor 'store' option since options and selectedOptions don't know about each other, alternatively, I could try to cache the passed in view models in the store for the collection observable when they are received (eg. replace the cached value). I suppose option 2 is better since it doesn't require use action but I need to look into the lifecycle/ownership implications.
Again, thank you...ill work on this today.
@mentat : I've followed @xdenser 's advice (thank you!) and it seems to work. Of course, it you want more fine-grained control over the timing if you could sync a relationship in the background, you should copy the collection. Also, I need to test memory management further.
Please take a look at 0.16.0beta1 in master and the working version: https://github.com/kmalakoff/knockback/tree/master/test/issues
@kmalakoff @xdenser thanks for your thoughts on this. I think this should work great.
As far as my thoughts on keeping track of removed models, etc. I don't think that is necessary in this use case. The reason I say so is that the sub-collection is always a subset of a master collection (there "things"). This means that any time the select-multiple is set the sub-collection is reset with the subset of items from the master ("things").
@mentat happy to hear it meet your use cases. These things can be difficult to extrapolate so I'll leave it here for now
and will wait for any new use cases.
I'll try to finish a 0.16.0 release in the next few days (from here mainly memory management, library size, updating and deprecating APIs, and website examples/tutorials around customizing view_models/create functions for embedded models). If you have any other recommendations or comments for the next release, I'm all ears.
I've released 0.16.0 so closing this.