Hi Michel
Makes complete sense, especially the formatter getting data from else where.
I agree the default way to display data is via model binding, preferably from the model and type that fetched the data in this case ODataModel. My suggestion for the formatter originally was to use the bound properties passed to the formatter to derive a path that can be used to populate a model to provide data back to the view, timing wise this probably isn't the right place to do it, the data should be in an accessible model before the formatter is used.
"Maybe you'd even never bind your oData model to your application elements but only models generated from the odata model"
I have seen some really good solutions built using this type of technique, there is quite a few standard apps on HANA built using this technique ODataModel <-> JsonModel and they were built because as you suggested a limitation in ODataModel getting the application data.
My observations having had to use, build upon or re-factor these solutions, often this data layer is built more on perception of limitation with the ODataModel than actually limitation. If you study the unit tests for the ODataModel and Mockserver you will see there is a lot that the ODataModel can do that isn't shown in the doco or sample apps, if there is a limitation in getting the applications data, the first place to look should be the design of the API. The problem is see with the data layer is the more code that uses this layer the harder it is to replace.
i would say a second model is a smart suggestion, get the data into the model then you can bind it, views can have multiple named models, binding can then be done early or late, why shouldn't the second model be an ODataModel also?
I like your comment, very well thought out. I am not sure this thread however was the right one for this level of thought, I am still even now unsure of the actually problem / requirement and without seeing the code I was guessing.
Cheers
JSP