Enhancement Request: Being able to add XMLComposite to explicitly typed aggregations

Motivation

Several controls await specific type in their aggregation instead of just sap.ui.core.Control. E.g.:

• Page’s custom header/ footer awaiting controls of type sap.m.IBar
• ListBase awaiting controls of type sap.m.ListItemBase
• (and more…)

Problem

In the latter case, sap.m.CustomListItem is an often used control to have a customized layout consisting of any desired controls. To encapsulate the customized list item, there are mainly two options:

1. Using as a fragment

   <items>
     <core:Fragment fragmentName="my.CustomListItem" type="XML" />
   </items>
   

   <!-- Fragment definition of my.CustomListItem -->
   <CustomListItem xmlns="sap.m">
     <SomeContainer property="{model>/property}">
       <!-- ... -->
     </SomeContainer>
   </CustomListItem>
   

   Drawbacks

   • Binding infos are already defined in the fragment definition. One cannot use the same fragment in a different context with different bindings declaratively.
   • Fragment is designed to be view context aware (unless it’s a control in the static area) encouraging tight coupling with a specific view or application.
   • Behaviors aren’t meant to be encapsulated either.

   So it’s not really encapsulating.

2. Creating a custom composite control by extending ListItemBase or CustomListItem

   Drawbacks

   Compared to the first approach where we could assemble controls declaratively, it’s more complex and error-prone.

   

   ^{Source: UI5con 2018: News from Control Development by @akudev}

This leads to the (currently experimental) XMLComposite approach.

What is the expected result?

The extended XMLComposite control, which has CustomListItem as the only root control (see fragment definition above), can be added to the <items> aggregation of the ListBase control.

<List xmlns:custom="my.custom">
  <custom:MyCustomListItem ... />
</List>

What happens instead?

I’m not allowed to add <custom:MyCustomListItem> since it’s not of type sap.m.ListItemBase, even though the top control is CustomListItem which is extended from ListItemBase.

After all, XMLComposite borrows the idea of Fragment. And fragments don’t have their own representation in DOM. Following this concept, it would be nice if <custom:MyCustomListItem> is treated as <CustomListItem>.

Any other information?

Same issue: https://answers.sap.com/questions/754215/composite-control-xmlcomposite-for-a-listitem.html

[mzimnn]

I think it’s really unfortunate that the XMLComposite has been deprecated. Is there an official alternative we can be used instead?

[codeworrior]

I think the problem is with (the missing) multiple inheritance. Typed aggregations only allow instances of the specified type or subclasses thereof. If the type is an interface, implementations of that interface are expected.

But XMLComposite is a base class by itself. It is not a feature or mixing that can be used to implement a subclass of another control class. Therefore, it is not possible to implement an XMLComposite that fits into a typed aggregation with a non-interface-type (interface types shouldn’t be a problem).

Fragments solve this problem by “disappearing at runtime”. Only the type of their root content has to match the enclosing aggregation.