Please support a server model that not require odata service, just an URL and customs params

[eusebio-garcia]

Hello, i saw on your online docs that OpenUI5 support 4 types of models

OpenUI5 provides the following predefined models:

• The JSON model can be used to bind controls to JavaScript object data, which is usually serialized in the JSON format. The JSON model is a client-side model and, therefore, intended for small datasets, which are completely available on the client. The JSON model supports two-way (default), one-way and one-time binding modes.
• The XML model is a client-side model intended for small datasets, which are completely available on the client. The XMLModel does not contain mechanisms for server-based paging or loading of deltas. The XML model supports two-way (default), one-way and one-time binding modes.
• The Resource model is designed to handle data in resource bundles, mainly to provide texts in different languages. The Resource model only supports one-time binding mode because it deals with static texts only.
• The OData model enables binding of controls to data from OData services. The OData model is a server-side model: the dataset is only available on the server and the client only knows the currently visible rows and fields. This also means that sorting and filtering on the client is not possible. For this, the client has to send a request to the server. The OData model currently supports OData version 2.0. The OData model supports two-way (default), one-way and one-time binding modes. However, two-way binding is currently only supportes for properties, and not for aggregations.

Please can you support a new server model that does not require an OData service on the server?

For example, KendoUI data source you define

dataSource: { type: "json", transport: { read: { url: "URL of server service", type: "POST", dataType: "json", data: additionalDataFunctionToServerFiltering } }

This way we can implement the server side part with minimal requirements, for already implemented server part, it is easier to provide a custom model than migrate all server implementation to support OData. Maybe the implementation could be like:

var oModel = sap.ui.model.ServerModel("url-to-server", "POST");

oModel could have events so we can hook before a request is sent to the server to add custom data for filtering the results.

Syncfusion components for example, have an URL adaptor that can be used to support this kind of scenarios, and also support OData services in their Grid.

Can you provide a new model implementation that does not require an OData service on the server?

Thanks.

[qualiture]

It already exists :)

How about var oModel = new sap.ui.model.json.JSONModel("http://www.yourdomain.com/rest/yourservice");

From the API doc at https://sapui5.hana.ondemand.com/#docs/api/symbols/sap.ui.model.json.JSONModel.html, the constructor accepts "either the URL where to load the JSON from or a JS object"

[matz3]

Valid requirement. Our JSONModel is very limited and there is a lot of custom code required to use it with a Restful-API (no OData).

@qualiture this works for read only (one time). But there's no way to post data back or do pagination, etc.

[eusebio-garcia]

qualiture: JSONModel is a client model, it reads the data once, what about server pagination and server filtering? Do you return a million of records in one query? Only ODataModel support that kind of scenario, i think that a custom server model could made OpenUI5 a better framework, the API details is up to SAP developers, as long as we as developers can hook on the model without pain.

[qualiture]

@eusebio-garcia, @matz3 You are totally right, I misinterpreted your requirement...

Actually, I have built a basic "RESTModel" a while ago, which is basically an extension to JSONModel with additional create, update and delete functionality. I will try and dig it up tonight

[eusebio-garcia]

@qualiture I'm pretty new on OpenUI5, i feel that i don't have the skills yet to make a complex contribution like the implementation of a rest model, i would really appreciate if you can make a contribution like this, no only me, the entire community

[qualiture]

@eusebio-garcia See https://github.com/qualiture/ui5-restmodel

I haven't used it in a long while, but hopefully the readme is explanatory enough. Basically you have a create, update and delete function, and by default it loads all the (updated) data from the specified service url.

Beware, it is really rudimentary, so no paging, lazy loading, filtering etc (although it's fairly easy to implement, the main logic sits in your serverside RESTfull service anyway :smile:
It's just basic CRUD, but it can be "easily" extended to accommodate those requirements -- I just haven't had the need for it

Hope it helps a bit, and hopefully you can use it for your own good (and I welcome you to make updates on it where others can benefit from as well)

[eusebio-garcia]

@qualiture Thanks, i will give it a try and see how can i hook to implement paging and all that stuff...

@matz3 I see that the issue is tagged as an enhancement, how can i know when this requirement can be implemented? This same issue is changed or do i need to see it in other place?

[matz3]

@eusebio-garcia I just marked it as enhancement rather than e.g. "bug". This doesn't mean that we will implement this in the near future (or not). It still needs to be clarified if this should be something part of the framework.

@qualiture thanks for sharing!

[eusebio-garcia]

@matz3 Thanks for your answer, i hope this requirement get implemented, OData is very powerful but also very complex and exists a lot of apps that does not have an OData service, just REST and even classic web services with XML.

@matz3 or @qualiture Exists a good tutorial on which i can see how the table control interact with the model, so it can help me to implement server paging, filtering and lazy loading? I will implement that and later make a contribution to the community, but i need a little of help on this. In some point the table must ask the model about the data, maybe that method is the one that i need to implement in a new model, how the table call that method is important, i think for example, in pagination, i need that the table send the current page or number of rows to skip....

[akudev]

Interesting suggestion... this topic has come up many times, so it seems to be worth looking into.

At the same time it always makes me wonder: how will this RESTModel look in the end? Will it really be so much simpler than OData? When we are talking about paging, server-side sorting etc., we need to define a protocol, something that both, server and client, understand. We need to define how we tell the server that we now need the "page" with items 40-60. REST is not a protocol, it's just a principle for architecture. REST says something like "use PUT to edit data", but it doesn't say how we specify we want to edit the data for player 15 in our current collection:

• PUT http://xy.de/service/players/15
• PUT http://xy.de/service/players(15)
• PUT http://xy.de/service/players/{15}
• PUT http://xy.de/service/players/Hugo (because player "Hugo" has number 15)
• PUT http://xy.de/service/players/number/15
• PUT http://xy.de/service/players?id=15
• POST http://xy.de/service/players/15 I'm sure that each of these ways to address an item is implemented in one or the other REST API. But we need to define the one used by our model.

And as soon as we are defining a protocol, we are in the OData ballpark. There are much more complex questions than how to address which data element we are addressing. All the same difficulties and requirements will come up sooner or later and make the protocol more complete - and more complex. And we need a server implementation that speaks the same protocol. Are there popular simple alternatives to OData? We wouldn't want to re-invent one...

I'm totally in favor of having such a model and supporting an alternative to OData, I just wonder how it can be kept simple. I currently feel "restricting its functionality" is the only way.

Regards Andreas

[eusebio-garcia]

@akudev Actually a Rest model is very simple, the protocol is defined by a developer, look at Telerik KendoUI or Syncfusion components as an example, almost all good frameworks and widget toolkits support the three common scenarios, local, Rest and OData, i wonder why OpenUI only support 2....

Here is an example of how it is done with KendoUI, if you look at that sample you will see that they left developers make their own protocol (since it is their own rest service too), the only thing that you must define is that the list method will sent you pageIndex/pageSize and the datasource need that the returning list will be an object with a Data parameter, if your service return other thing, you can add an adapter and return the data.....

dataSource: { type: "json", transport: { read: { url: "URL of LIST method", type: "POST", dataType: "json", contentType: "application/json", data: functionOfAdditionalDataToFiltering }, create: { url: "URL to create", type: "POST", dataType: "json" }, update: { url:"URL to update", type: "POST", dataType: "json" }, destroy: { url: "URL to delete", type: "POST", dataType: "json" }
.........

It is very simple, maybe on OpenUI could be like this

var oModel = new JsonRestModel({ read:{},//definition of read, list, get or some other name create:{},//definition of create ...... //rest of defined methods });

and if some parameter is missing, for example the protocol, use conventions, for example POST to insert, PUT to update...... I know WHAT to do, but i don't know HOW......

[matz3]

@eusebio-garcia that fits to what I had in mind. The model just needs some basic API (read, write, update, delete) and could even have something like paging but leaves the protocol to the developer so e.g. you have to implement some callback which creates the URL for a paged request.

@akudev what do you think? I would label this as contribution welcome to get some more API proposals or even implementations. Then we may see if it works out or not.

[eusebio-garcia]

Exactly, that is what i think, just implement a basic and common API and leave the details to developers, i also think that the model must leave a couple of doors opened in order to hook the implementation e.g before send request, after request, before binding, etc... you get the idea.....

[matz3]

@eusebio-garcia while I can not guarantee that this will make it into OpenUI5 please feel free to share some ideas or even code. It might also be a possible candidate for a project here: https://github.com/UI5Community

[Megale]

Any sugestion on how to use the “growing” property of lists and tables with a jsonDataModel? I too have a requirement of building a sapui5 frontend that consumes an existing restful style backend (no odata)

[amosang]

Hi, Stumbled on this old thread as it was the top 3 results in Google search (Keywords used: "UI5 without OData"). I'm pretty new to UI5 as well, and am facing similar challenges as first mentioned by @eusebio-garcia . Has there been any updates since then? Cheers, Amos

[avh-sap]

There is an open source library https://github.com/mauriciolauffer/openui5-model-json-crud that might help you. But for productive environments I would always recommend using OData.

[flovogt]

Hi @eusebio-garcia , we discussed this long ongoing requirement multiple times in the respective teams. Currently, the capacity is fully blocked by other requirements, so this enhancement will not be developed in the next months. Also, there are already multiple community projects available covering this scenario:

• https://github.com/mauriciolauffer/openui5-model-json-crud

• https://github.com/clouddnagmbh/RestModel https://blogs.sap.com/2020/06/23/restmodel-for-sap-ui5/

• https://github.com/qualiture/ui5-restmodel

There might come such a generic RestModel but not in the medium run. Therefore, closing this issue.

[pubmikeb]

@flovogt, the official and out-of-box support of the full-fledged RESTful API Model can contribute to wider use the framework, since the standard RESTful API is much more common and widespread than OData, thus OpenUI5 can easily replace an alternative frontend frameworks used today without any or with minimum changes on the backend.

Hopefully, the RESTful API Model support will land to UI5 in some later but still reasonable time.