Background
I'm working in a client-server REST based application which manages various kinds of information and defines a generic EntitiesCollection which extends Backbone.Collection.
The EntitiesCollection has an API (it extends the Backbone.Collection API) for CRUD operations, filtering, sorting and so on.
My team needs to write a Grid component which can display and manipulate an EntitiesCollection object. This grid will be based on some 3rd party component and we are seriously considering using Kendo.Grid.
The Challange
My first question is whether anyone ever tried to use Kendo.Grid whose data\data-source is actually a Backbone.Collection and whether that is a good and applicable idea at all?
I have seen various articles regarding Kendo and Backbone integration including Derick Bailey's Backbone And Kendo UI: A Beautiful Combination. However, these articles talk about view level integration (wrapping the Kendo.Grid with a Backbone.View). What I am looking for is data level integration - making Kendo.Grid work with Backbone.Collection.
Options
As far as I understand so far Kendo.Grid works with a Kendo.DataSource which in turn holds an internal collection - a Kendo.ObservableArray.
Assuming we are going for it I see several implementation options:
One of the options we discussed is converting our EntitiesCollection to a Kendo.DataSource however this seems to be a non option - the communication with the server has to be done through our own objects.
Replace the Kendo.DataSource with the EntitiesCollection - our EntitiesCollection will implement the Kendo.DataSource API and the grid will work with it as its dataSource object. I don't like this solution since I think I will loose a lot of the functionality that Kendo gives me in the Kendo.DataSource object.
The Kendo.DataSource will wrap our own EntitiesCollection and delegate requests to it.
The Kendo.ObservableArray object contained by the Kendo.DataSource will wrap our EntitiesCollection (see this sample implementation I found online). This approach seem to work with simple use cases however something seems wrong to me - I think that the Backbone.Collection is not the data object (in Kendo terminology) but the DataSource object - since it is the one that interacts with the remote server and fetches the data.
You might be interested in this article that I just posted:
http://www.kendoui.com/blogs/teamblog/posts/13-02-07/wrapping_a_backbone_collection_in_a_kendo_data_datasource.aspx
In it, I walk through the basics of what it takes to build an adapter to use a Backbone.Collection as the backing store for a DataSource, and connect it to a Kendo UI Grid.
I haven't completely solved all of your needs - for example, no paging support - but hopefully this will get you down the path far enough.
All Kendo UI widgets (grid including) can bind only to an instance of the kendo.data.DataSource.
I created the 'kendo-backbone' project to show a possible way to integrate Kendo UI with Backbone. The project wraps an existing Backbone Collection as a Kendo ObservableArray. The latter acts like a simple proxy and works entirely with the Backbone collection.
Related
I'm currently facing one of the most discussed problems in MVVM: I have a complex Model in my WPF application and I'm not sure how I should display its data to the View.
According to many answers here on StackOverflow and also to this article there are two ways:
to wrap the Model inside the ViewModel by adding a property in the ViewModel for each property in the Model
to expose the Model directly to the view without replicating the properties.
What I understood so far is that the first approach is better from a theoretical point of view, while the second one is a quick shortcut that should be avoided.
In the same article I previously linked, the author writes the following:
In reviewing the sample application from the Caliburn framework, they implement the VM using option 2.
I took a look at the Caliburn.Micro documentation and unfortunately it just uses a simple ViewModel without a real Model, so I don't know how to verify this statement.
Is the author right? Since I'm using Caliburn.Micro should I use the second approach instead of the first one in order to be more "compliant" with the framework implementation?
Since I'm using Caliburn.Micro should I use the second approach instead of the first one in order to be more "compliant" with the framework implementation?
No. Caliburn.Micro is just an MVVM library. How you implement the actual MVVM pattern is entirely up to you.
I agree with #Marek Dzikiewicz that you should wrap the model in a view model class that may implement the INotifyPropertyChanged interface and provide any other UI specific functionality. This code doesn't belong to a business object. You could refer to my answer here for more information:
Reuse the same models in ASP.NET MVC and WPF MVVM
Obviously if the model class is indeed a UI specific class that is not used in any other application and doesn't contain any business logic that is used on the server side, you could modify this class and bind to it directly. But then it is kind of a (sub) view model after all.
Usually it is better to expose view models because that allows you to add additional properties to control the way the data is displayed (for example formatting or concatenating data). However, if you don't need that, there is nothing wrong in exposing the model classes directly.
I am in midway implementing an UndoRedo container for a view model that contains nested properties and ObservableCollection. I am using PostSharp for Exception Handling in the application and thought of reusing it for implementing an undo-redo engine as stated in the article:
http://www.postsharp.net/aspects/examples/undoredo
Although the above article is for windowsForms which had binding limitations, I have made the engine to adopt the rich binding wpf platform and it is working nice for single properties.
I am wondering how to extend the UndoableAttribute to take care of Nested properties and collections. My tries and googling skills have proved futile till now. Any idea, or pointer to some article would be appreciated.
It really depends on what you are after. Providing undo functionality on object graphs can be quite complicated task. You would have to state more specifically what you want to achieve.
Generally you could instrument all nested objects and write some specialized collections to store all changes in some kind of global container.
We are working on providing such a functionality as part of future release of PostSharp.Patterns libraries – it should make to 3.1 or 3.2.
I'd like to create a Silverlight app using WCF Ria Services and the MVVM design pattern.
The main page of the app will consist of a "shell" and a large number (10s or 100s) of objects of different look (shape/size/properties) linked to each other (forming a sort of graph).
These items need to be mouse-draggable and their current position/state needs to be saved to the back-end database.
I feel that the best way to achieve this would be to have a small ViewModel and View for each item displayed, put all the important properties into the ViewModel and then somehow display all these Views in the main "shell".
However, I don't know how exactly this could be achieved. I considered using MVVM Light, but didn't find any example that would show something similar.
Can anybody point me to some examples or ideas about how this could be done?
"When all you have is a hammer, everything looks like a nail" :)
MVVM is not designed to manage graphic intensive situation like the one you describe. It is a glue for stitching together high-level concepts in a flexible manner. With MVVM you are adding overheads that will impact performance (e.g. binding uses reflection behind the scenes). The more objects involved, the greater the impact.
The best starting point I can suggest is to imagine what you need from a 3rd party control (e.g. a custom control/container) and, if one does not actually exist already, build it as if it were a third party custom control.
You will find in practice that custom controls are seldom based on MVVM, for performance reasons if not just because "they often don't need it". They may well expose MVVM compatible properties for the external interface, but not for the low-level internals.
MVVM is a relatively high-level technique. Do not feel you have to implement it on everything.
Following MVVM do the next:
Model - create model object which will be responsible for fetching and persistence coordinates of the shapes on the screen;
View Model - one view model which will initiate fetching and persistance model objects;
View - in your case, it's a place where you do most of your work. Create custom control based on ItemsControl with Canvas panel. Custom control should pass collection of the model objects in ItemsSource, allow to drag and drop containers and call the view model command when user drops container in some place
Have a look at the Telerik controls, specifically radTileView, this seems to have the functionality that your looking for. They also have a persistance framework that should allow you to save the position of the tiles back to you database.
I have defined a model within it I have default model schema. I have a respective collection and views defied for it.
I have the model data stored as documents in Couchdb.My question is, How can I render these items in a browser.
I guess I am missing something small here with regard to linking the db and backbone.js. A little bit of direction would be very helpful.
To display/visualize the data you need views. Backbone.js provides a very skinny views layer with no magic in built. So in almost all but the most simplest cases you would like to auxiliate your mvc architecture with some user interface widget framework like YUI to provide UI components like datagrid or visualization toolkits to provide graphs and charts.
Of course you can stitch in plugins or create your own ui components in the view layer.
Backbone.js provides absolute freedom of choice to you to use whatever ui components you like in your views and unlike sproutcore/ cappuccino does not provide a hardwired ui framework.
So you would create view classes that perform the job of rendering the ui elements either by doing the hardwork themselves or by delegating them to some external library. In a typical scenario you will have nested views to provide a robust and responsive application interface. Eg. in a gridview you can have a master view for the whole table and views representing individual rows. If you are using sophisticated cell renderers then you can have the cell rendering logic in further nested views.
I am required to use the Extjs framework in my next project. So what features are available in it? There are so many javascript frameworks available in the market like the DOJO framework.
In my opinion, the principale avantage of ExtJS is the Store mecanism. you can have a store which hold your data (as a database table) and tell some UI widget to display data from the store.
this is great because:
you bind your widget to a store, then it automatically update it's ui when element in the store are added/modified/deleted
you can easily display your data in multiple form without worrying about updating echa place (each widget update itself automatically)
others thing done right:
event
ability to extend ExtJS classes
How it stands up to competition...
To see how Extjs stands up to its competitors, you could review the impressive comparison chart hosted on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
Where to get it...
I'm sure you could find tons of information on http://www.extjs.com/. Keep in mind that you're going to pay a handsome fee to use Extjs.
How to learn it...
If your initial impression is good, you could peel into the Learning Center where you'll find API documentation, tutorials, and more.
To learn about different features, just have a look at the ExtJS Examples page. It should give you a good initial impression of what's available. There are grids, editable grids, tabbed views, trees, windows and other dialogs, menus, toolbars, etc.
Be aware that all of the functionality shown on the examples is not available out-of-the-box, though - some of them require you to include extensions (plugins) developed by the ExtJS user community.