Openui5: XMLView shall contain model definition also

[wernerdaehn]

OpenUI5 version: 1.76.0

Imagine you build an application with 10 combo boxes, each bound to a different oData endpoint to show the possible list of values in their items collection. Very likely you will call setModel(new ODataModel()) on every single control to bind their model as the default model.

Wouldn't it be nice if you can do that in the view directly? Something like

<view>
  <hbox>
    <combobox>
       <models>
         <model name="" datasource="manifestds1">
           <settings preload="false"....

Rational is

• You do not want all models to be on the root level, not when they are relevant to a single control only. A control somewhere deep within the control tree.
• XMLView is all about bindings. Why limit to property bindings? Also bind the model to the respective control
• This would also eliminate confusion when writing the view. How did I name the model and where is it attached to?
• View becomes the central point for all relationships between model and control
• Datasource definition in the manifest is fine, root models as well. But control-related models make more sense in the view definition. Else you would have 10 extra models definitions in the manifest.json and no clue what they are used for.

I see potential in that suggestion, do you as well?

[boghyon]

I agree with the general idea. It would be nice if application developers could set models declaratively close to where the relevant controls are actually used.

One of the special settings every ManagedObject has is models. But currently, many special settings can't be defined declaratively in XML views (similar enhancement request: https://github.com/SAP/openui5/issues/2873). Maybe XMLView could support some extended syntax for that, in combination with the core:require-syntax?

Something like this:

<MyControl xmlns:core="sap.ui.core"
  core:require="{ MyModel: 'path/to/Model' }"
  models="{
    undefined: {
      modelClass: 'MyModel',
      dataSource: 'sourceFromAppDescriptor',
      settings: { ... }
    }
  }"
  myControlProperty="{/value}"
/>

[wernerdaehn]

I am currently wondering if the app descriptor should be used at all. At the moment I am leaning more towards specify all in the view including the endpoint url and the model type.

[tsanislavgatev]

Hello,
I am closing the issue, as solution was proposed.

If any help is needed, the issue can be re-opened, otherwise, the comments are opened for discussion.

Best Regards,
Tsanislav

[wernerdaehn]

There was no solution proposed. It was said it is a good enhancement request. And we were thinking about the best option to implement it in the core of ui5.

[boghyon]

@tsaleksandrova Could you re-open this issue? This is an enhancement request to which I simply agreed. No solution was provided.

[flovogt]

Hi @wernerdaehn and @boghyon,

thanks a lot for bringing up this topic and this interesting discussion.

First of all, sorry for the delayed response. We've discussed this feature enhancement in the UI5 team heavily and over a longer period of time. This is the reason, why so long no updates where posted on this issue.

With the introduction of XMLViews coding UI5 is much more declarative as before. So, enabling the model creation in the XMLView would be only another step towards this direction.

However, we, the UI5 team, decided to not implement this feature enhancement. Let me explain the reason.
The development paradigm of UI5 is MVC. So, paradigm wise there would be no limitation of offering such fine granular models. However, the relationship of datasources (like web services, json files, etc.) is in general not bound to a single view or a part of a view. The data which a service provides could be theoretically shared via multiple views. Using the manifest.json you have a single point of truth of model declaration which then can be used in all views of your application. Also, for developers it's quite easy to know, where the model declaration is placed.
Yes, you're completely right. There might be scenarios where you have X UI5 elements all pointing to a different model. This would result to have more models with less data. The current model concept of UI5 is having few models with more data. So, in your scenario you could have a model containing all value help values and via the different binding contexts you can distinguish between the different values.

Implementing this feature would lead to an eased binding context concept and the model concept would take over parts of the current binding concept. The binding concept is quite powerful, like the binding context propagation, to mention only one of many benefits. Switching to more models would also lead to decreasing performance, because all models have to be propagated in the control tree.

Summing up, thanks a lot for this enhancement request and don't hesitate to bring up further topics.

All the best,
Florian

[wernerdaehn]

Thanks for the extensive answer and understood.
While I am not convinced it is the correct decision, there are examples for both approaches.
My biggest problems with the manifest file is that a) it gets way too large and b) it breaks the MVC concept also.

At the end it boils down to three examples:

• An application with a single master/detail view --> manifest with two models is perfect.
• A SimpleForm application showing data of a single odata service but 20 ComboBox controls --> manifest for the main odata service but the ListOfValues odata providers belong more to the controls
• A complex application consisting of 50 different screens with routing --> oh my, the manifest file will be horrible.

Thinking about it, a XMLView consists of the *.view.xml file and a *.controller.js file. That's not MVC either. How about adding a *.model file as well?
Essentially a mixture of our two approaches. Not the global manifest, not the view itself but a third file for each view to make it smaller?

Anyway, the important part is you obviously understood the request, you took your time to consider pros and cons and made a decision.

Thanks!

[flovogt]

Hi @wernerdaehn ,

thanks for your your detailed explained arguments. I totally agree with you, that the concept how UI5 interprets the MVC concept is also not unassailable.

Looking to your described examples:

• An application with a single master/detail view --> We are on the same stage. all fine 👍
• A SimpleForm application showing data of a single odata service but 20 ComboBox controls --> It dependents. The value helps might come via an odata annotation, so the odata model does the job for you. But yes, if not. Then you've to request the different value help providers via own models.
• A complex application consisting of 50 different screens with routing -> From my point of you, the ideal case is that the backend providing data for a UI should be a kind of UI mashup service. So, the UI5 is talking only to one service. If so, also large applications can be served optimally.

Regarding the *.model-file, I totally agree with you, would be an enhancement to the model concept. However it is not the direction how we wanna drive the MVC concept in UI5.

Thanks a lot for this fruitful discussion.