uhlmannm
commented
1 year ago Wherever possible the control should directly be bound to the ODataModel. That is not possible, though, in a filterbar. In that case, binding against a JSONModel with the proper type required in OData is the way to go. The values are transported to filter objects and not into the ODataModel properties. However, not every use case can be provided with the ODataModel. For some, like the V4 Tree we are on it. Until we are there, applications will be able to help themselves using a JSONModel. How to transfer the values should be shown here as well.
KlattG
boghyon
The content of the new topic "Dates, Times, Timestamps and Time Zones" is really top-notch and I believe it will be very helpful for application developers and customers understanding and learning best practices.
One thing I noticed is that the section "Best Practices" has several subsections for each one of the cases expectedly, except for the case regarding the JSON model ↔ OData model.
Current
Expected
It would be nice if the JSON model ↔ OData model case could also get a heading like the other subsections in within the "Best Practices" section. For example:
Alternatively(See @uhlmannm's reply below)In my view, explaining how to "transfer" data between JSONModel ↔ ODataModel is questionable since the case doesn't really reflect current best practices but rather encourages anti-patterns such as requesting a large amount of entities via
v2.ODataModel#read, storing the response in aJSONModel, then surgically manipulating the data manually instead of working with OData bindings.The JSONModel ↔ ODataModel case should be removed completely.