Okay so you load a model
Then you load a view:
Assume you had a layout object called myLayout:
This works just fine. Everything okay up to this point.
But the documentation doesn't seem to say anything about how you're meant to replace the model in that view and still have MVVM properly bind all the new values to the relevant HTML elements. There are only two methods:
- Destroy and
Are you supposed to:
- Reset the myModel properties back to defaults then set them to the new data that you want to display, or
- Instantiate a new View and Observable and render them by using ShowIn on the layout object?
7 Answers, 1 is accepted
Replacing the view model of a view is not supported by design. In addition to the data displayed, the view model is supposed to contain the various view component event handlers, so swapping it with something different will most likely lead to unexpected results. The envisioned way to perform such changes would be through a data item field reassignment - implemented in the master > detail navigation of the sushi example here. The application example source code is just a couple of screens, so you should not have any troubles understanding it.
Questions on this Sushi app:
- Are you saying that my suggested answer (point 1) is the correct way of doing it? Except that you're replacing the field with a different object?
- This is a very simplistic example. Does it make a difference if the Details data is extracted from a web service instead of from a local DataSource
- Where does "current" come from in detailModel.get("current")? There's no such field on the detailModel and it's not an Observable field either.
Seems your documentation needs to be updated to include the idea that you can randomly set obserable field values for fields that don't exist.
Also, the documentation could do with a better explanation of how this is intended to be used because a master > detail view is the most common application usage that one can find!
- the current field is set here.
- the datasource abstraction is meant to cover the local vs remote data differences.
In general, the approach I have suggested is just one of the many possible ones. Re-creating the view each time would also work. In general, the Kendo UI SPA toolkit is not a framework - you may pick just parts of it and use them in a way you see fit for your project requirements.
Thanks Petyo, but I think you might have missed my point about "current" in that it's a random property that doesn't exist on the actual object which means that Observables allow for these random properties to be added, but this is not documented.
Can you explain what you mean by the second poing about DataSource abstraction?
"You can define a property by assigning it a value."
The observable objects Kendo UI exposes are no exception to this behavior.
The datasource abstraction (including local and remote data) is covered in details in our documentation.Regards,
Specifically, the code above is a concern, because it gets "randomly" introduced instead of being properly declared as part of the object. So, if a team member were to be debugging code looking for the source of a problem related the property Current, they'd have a hard time because they wouldn't find it declared on the actual observable object.
Thanks for the link to the documentation. It was pretty much the standard stuff, I thought you may have been alluding to some pattern or practice that we weren't aware of.
Thank you for the feedback. If I understand you correctly, it looks like the purpose of the set() method and its relationship to the ObservableObject used by the Kendo UI MVVM pattern is not that obvious. Currently this relationship is documented at:
Please do share if you have any specific suggestions on where you would have expected the above information to be presented differently, so that it is better conveyed.