Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Active Participant
For more of my blogs about UI5 controls, please check the catalog here.

List is one of the most commly used control in UI5. With a list it's really easy to show a set of data. UI5 also provides us many types of predefined list items, such as sap.m.StandardListItem, sap.m.InputListItem. And to guarantee the extensibility it also provide us a sap.m.CustomListItem, which could be quite free style.

In my daily work there are 4 types of list items, that I mostly used. They are sap.m.StandardListItem, sap.m.ObjectListItem, sap.m.InputListItem and sap.m.CustomListItem. We will not talk about sap.m.ColumnListItem because it's used in a responsive table but not a pure list. So we won't take it into comparison.

Firstly we all have to know that all these 4 list items are extended from sap.m.ListItemBase. So they have some common properties and functions. Such as counter, highlight and selection behavior (See following image). And then we could have a look how these "siblings" are different from each others.


Maybe because of its name, sap.m.StandardListItem is the first list item for many people, when they studied UI5. And I also think so, that it could be the most commonly used list item. Let's have a look what additional properties it has based on sap.m.ListItemBase.

Now we could set basic information in our list item! We got a title, a short description, an image and a semantic information. Normally these information is quite enough for a user to identify an item. But it is only enough for item identification. User could not get detailed information from it. So sap.m.StandardListItem is mainly used in a select dialog or a master list.

My personal opinion of sap.m.StandardListItem is, do not show the semantic info and the counter at the same time. Because they are quite close to each other.


Sometimes a title a description and an info are not enough to represent an item. In this case we could apply sap.m.ObjectListItem. In principle with the aggregation "attributes" we could have unlimited info displayed in the list item. But it still not recommanded to use ObjectListItem to represent all the info. Normally we use ObjectListItem in the mater list of a master-detail-page. Since the size is too big we should not use it in a select dialog.

We need to pay attention that many texts in a sap.m.ObjectListItem cannot wrap, which means we should keep the text short. One possible way to do so is use a formatter, for example, show 1.7 B instead of 1,659,963,900.42 is more responsive.

There is another fiori guideline we should take care is, when showing date in the title please use long format, but in attributes part please use medium format.


Different from the previous two list item, InputListItem is normally not used for representing a list of data, but some key-value pairs. So it's more likely a form. For this reason, in most cases we won't show the counter in a InputListItem.

In the content part you could have everything you like, but it's not recommanded to have too complicated content there.

From the fiori guideline we could see the InputListItem was normally used in the old time. But now to support multiple devices it's recommanded to use a form insteadly. But my personal view is, when there are only a few key-value-pairs it's better to use InputListItem, because the layout looks better than a form.


In most cases the above mentioned 3 types of ListItems could cover your usecases. But sometimes there will be exceptions. Then you could come to CustomListItem.

When I firstly played around with this control I found it was really powerful and flexible. But if something is flexible sometimes it means the logic is very simple. And so is CustomListItem. If you check the source code, basically it just provide an aggregation content, and it accept everything. And in the renderer it just invoke the renderer of the content control to render the content.

Flexibility is a double-edged sword. As the Fiori Guideline we must consider the guidelines by ourselves to garantee the UI consistency.