Missing support for nested composite bindings

[dfenerski]

Are there any plans to add support for nested composite bindings? IMO it would be helpful as there are plenty of use cases for it, the docs confirm this.

Thanks in advance for the info

[boghyon]

Could you give some use cases where a nested composite binding is required? And why are existing solutions not sufficient?

[dfenerski]

text="{i18n>resultLabel} {= ${model>/obj}.result}" is impossible text="Length: {= ${model>/items}.length}" is impossible text="{model>/userName}: {= ${model>/obj}.result}" is impossible.

Generally speaking, an expression binding cannot be combined with anything else.

This is cumbersome because should you want to enhance the displayed information with e.g a label or extra info from the model, you can't and have to write extra code.

IMO expression bindings are powerful tool that saves writing excessive code in controllers and formatters for common inline calculations. There are alternatives, but none with the convenience of an inline expression.

[ThomasChadzelek]

Hello @dfenerski !

text="{= ${i18n>resultLabel} + ' ' + ${model>/obj}.result}" is possible text="{= 'Length: ' + ${model>/items}.length}" is possible text="{= ${model>/userName} + ': ' + ${model>/obj}.result}" is possible.

Generally speaking, an expression binding need not be combined with anything else ;-)

Best regards, Thomas (one of expression binding's fathers)

P.S.: I do not object the nesting of composite bindings, but for sure there are other reasons for that.

[boghyon]

As Thomas mentioned, these are actually possible: https://jsbin.com/wihiwuw/edit?html,js,output

Only if the composite binding contains another parts within, it's not possible currently. E.g.:

text="SomeStringLiteral {= ${parts:['model>/obj']}.result}"
      \                      \_Composite_Binding_/       /
       \______________Composite_Binding_________________/

The documentation has been recently enhanced accordingly in ManagedObject.PropertyBindingInfo:

Note: recursive composite bindings are currently not supported. Therefore, a part must not contain a parts property.

[dfenerski]

Hi @ThomasChadzelek ,

I know that 'concatenation' within the binding is possible, that's what I've used as a workaround. My concern is that it makes the expression logic more complex by inducing an artificial concatenation in it and making it even longer.

BR, Dimitar

Edit: Would a recursive binding in theory allow for dynamic binding expressions e.g context binding to a variable array index?

[boghyon]

@dfenerski Sorry for the late response. Could you confirm whether the recursive composite binding with parts shown at https://github.com/SAP/openui5/issues/3565#issuecomment-1206774715 is what is expected to work? Or is it no longer required by now?

---

Would a recursive binding in theory allow for dynamic binding expressions e.g context binding to a variable array index?

I doubt that it will be made possible anytime soon if I understood it correctly.

[dfenerski]

@boghyon while I opened the issue initially for the nested use case which is not supported, I've come to terms with the limitation. More complex expressions work fine in a JS context and one can argue that adding XML support for them is like reinventing the wheel, to which I agree.

My initial reason for pursuing such binding expressions was so that I don't "pollute" formatter classes with "too many" "formatters". However there are other ways to manage complexity on project level, which alleviate the "pollution" problem.

IMO this can be closed if it's (way) out of scope.

[boghyon]

Ok, the recursive composite binding doesn't seem to be highly requested so far. I haven't seen any similar request from other UI5 related community sites either. As there are probably other ways to reduce the complexity you mentioned, I'd say we can close this for now.