For a openui5 component I need to bind multiple models and is investigating what the best way to do this is.
The models are both JSONModel and XMLModel.
The background is that I want provide the user choice of multiple source to use for the custom openui5-spitz-reader component https://github.com/elsewhat/openui5-spritz-reader
Each of the selection the user can make (BBC World News, Reddit /r/worldnews), has a single Model populated.
During runtime, I need to combine all the Models the user has selected and bind the combined content towards the items aggregation of the openui5-spitz-reader component.
You can use named models on aggregations see Multimodel Support - example using multiple models on an element JSBin OData Model dynamic column and data binding
I am not sure if you can bind data from 2 models on a single aggregation, you may be able to achieve it using a factory function with the aggregation or a handler on the model binding - using a generic binding to sum aggregation
Related
I'm reading data from HANA using a JSONModel and simply passing in the URL to the source and retrieving it as in the following:
var data = new sap.ui.model.json.JSONModel(urlPath);
Then I can bind it to my view: this.getView().setModel(data);
I have also seen the following way of doing it, where an ODataModel is created and then the JSONModel is created from the data.
var oModel = new sap.ui.model.odata.ODataModel(urlPath);
oModelJson = new sap.ui.model.json.JSONModel();
oModel.read("/Items",
null,
["$filter=ImItems eq 'imputParameter'"],
null,
function(oData, oResponse) {
oModelJson.setData(oData);
},
null
);
What difference is there in creating the ODataModel first than creating the JSONModel at once. So assuming I'm getting back from the database about 5,000 data points, which approach should I use, or would there be no difference?
JSONModel is a Client model to get the data and set data to the view for JSON format.
ODataModel is a model implementation for OData protocol.
This allows CRUD operations on the OData entities. JSONModel doesn't support Create/Update/Delete/Batch operations.
So coming to your scenario, I would suggest to use ODataModel always to do CRUD operations (inclusive of read). Then can use JSON model to bind the data to view.
Note that it's better to have one ODataModel per app and multiple JSONModels bound to views.
Consider using ODataModel V2 and since you have mentioned that you are dealing with 5K data points, if you don't all the data in the UI. Use setSizeLimit to make sure you have set proper upper bound.
Both models can be used without conflict. In fact, most applications will use both.
You want to use the OData model to send/retrieve data from the server. The OData model will handle building the URLs for you. For instance, if you want to filter, sort, or use paging in your data without the OData model, you will need to build the URL yourself.
yourUrl.com/EntitySet?$filter eq Property1='Value'&$sort= ..... &top=... etc.
This will be difficult without the OData model, and makes the application more difficult to maintain and debug. Let the OData model do that for you:
ODataModel.read("/EntitySet, {
filters: [new Filter("Property1", "EQ", "Value")]
});
The greatest benefit of the OData model in my opinion, though, is binding directly from the XML views.
<List items="{/EntitySet}">
<items>
<StandardListItem title="{objectTitle}"/>
</items>
</List>
This will automatically call the backend, retrieve the data from the entity set, and bind it to the list. No need to construct any URLs, make any calls, etc.
Using a JSON model to retrieve the data from an OData service will only make things more difficult than they have to be.
But... that being said... the JSON model is a very powerful tool. You can use it to store configuration data or any data you want to hold in the UI and manipulate. You can use the JSON model as sort of a mini-database in your application that can pass data globally across your application.
To summarize, you should use the OData model to get/send data. You should use the JSON model for local data storage. There will not be conflicts trying to use both.
One major difference between both of them is:
A lot of controls in SAPUI5 for instance, smarttable, bind automatically to the odata entities, meaning it dynamically creates the columns and the tuples based on the Odata metadata XML file. In this scenario, you cannot use a JSON Model.
IMHO, I would go with OData because of this "automatic binding" that a lot of components SAPUI5 have. But, I also ran into scenarios when the OData entities were not structured well, meaning the "automatic binding" that some SAP UI components had, did not work as expected.
In those scenarios, I had to get the JSON out of the OData, created/destroyed a few properties and then I did the bind to the mentioned SAP UI component.
I am using inheritance currently in EF and feel like it is causing more issues than it is helping, especially with binding an aggregation of tables to a datagrid. I have given a screen of part of the model. What I am trying to do is bind FREQUENCY to a datagrid, and have the grid fields be based on the type of FREQ_POOL(which is a base class). So for instance, if I want a POOL_IA datagrid, then it would have those fields, as well as the few fields in FREQUENCY. I was using inheritance because it made since from an OO perspective. The alternative is to just have lots of 0..1 relationships that show the ability for FREQ_POOL to have an extension, but then I have no constraint in place saying that FREQ_POOL can only be ONE type. What is a better design to accomplish this and make data binding easier? Thank you for any guidance.
One approach may be creating a data grid that gets the data from FREQ_POOL and then put all the variables of POOL_IA (or the all the properties of derived class using reflection) and FREQUENCY .
If you really don't need using objects while binding your data grid and able to use DataSet the another approach may be getting all the properties and the values of entry with Context.Entry method on the fly and put it into DataSet dynamically.
I have a quick (hopefully) question on how to implement a composite field using MVVM.
I have 2 examples, one is on the sql end I am storing gps coordinates in the following manner "Latitude,Longitude" for instance "45.55555,-80.00000". the other example is storing feet and inches as a single double field with it being ft.in.
How should I go about this? Should I have two fields and in the model or Viewmodel composite them if the other piece exists? Should I bind them to the same field and somehow validate the sets?
thanks!
In the Model I normally use a structure/layout that is closest/easiest to the source so it can be easily/quickly read and written.
In the ViewModel I aim for a representation of the View to accommodate the bindings.
In general I make the ViewModel responsible for the transformation between the Model and ViewModel.
So whether or not a property of the ViewModel and the Model should have one field or two depends on the requirements of the View and the Source.
I'm completely new to M-V-VM and very new to Silverlight, just reading about it for the first time today. As a sample, I am creating a model containing a list of items. My (Silverlight 4) View contains a listbox and my ViewModel will look to the model to retrieve the collection that the listbox will bind to.
My question is this. I think it would be good to use an ObservableCollection to hold the items that the listbox binds to. This would be an ObseravleCollection in the ViewModel. Should I also use this type of collection in the model, or should I use another collection type and do smoe conversion between model and viewmodel?
There are 3 basic scenarios (in order of increasing complexity):
model simply provides an access to a backend services and does no caching of data flowing through it at all
model exposes a collection of items, vms don't have their own collections, and then views are simply bound to collection in model object
model exposes a data source, vms have their own collection that serve as window into this data source, and views are bound to collections in vms.
In first case you'd use List to simply pass a requested data to vms, in other cases you'd use ObservableCollection so that either views will be properly updated via binding (case #2) or vms can properly update its own collections (case #3)
the usual way of doing this is to use IList/List or something similar in the model and then do a conversion in the ViewModel. So in the model you will have something like IList and in the ViewModel you convert it to ObservableCollection (usually in the ViewModel's constructor).
Cheers, Alex
I am trying to get my head around business entities that you want to list in a grid or list where a user will pick one to edit/view.
Lets say I have an Entity that have a lot of properties and collections, but my Grid will only display like 2 properties to the user. Besides using lazy loading on collections what would be the best / efficient way to load this data and display to the user?
I am thinking of creating a DTO object with the required properties and pass that to the UI. But I am worrying about over populating DTO's.
To do maintenance on an object you could allways use a Property Grid control if your are in c#.
With this you can view/edit collection and everything else.