Show counter / index in SAPUI5 List Control through XML view

Based on my knowledge, there is no built-in "pseudo-property" that would contain the index of the element. If we especially think about sorting, then I would imagine that there would be developers wanting the numbering to reflect the sorting and other developers wanting it to be stable with regards to sorting.

Nevertheless, in some concrete cases, it is possible to actually number your rows using a pure XML solution.

If the MyRootElement is an array, you could always do something like (working fiddle):

<List items="{/MyRootElement}">
    <StandardListItem title="{name}" 
        counter="{= ${/MyRootElement}.indexOf(${}) + 1 }" />
</List> 

If it is an object (i.e. a map-like structure) then you will need to use the Object.values() function. It provides the correct numbering because it is guaranteed to give the values in the same order as a for .. in loop which is actually used by the Model to create the bindings and ultimately the list items. It should be noted that the Object.values() function is not supported in IE and might require a polyfill. Example (and working fiddle):

<List items="{/MyRootElement}">
    <StandardListItem title="{name}" 
        counter="{= Object.values(${/MyRootElement}).indexOf(${}) + 1 }" />
</List>

Later edit: Binding path explanation

In the code samples, I have used the ${} construct to access the current, unnamed model's binding context's data object.

The rules related to building the binding paths are the following (as specified in the documentation):

• The model name followed by a > sign. If this part is skipped, then the unnamed (default) model is used. The rest of the path after the > sign is used to find the referenced data inside the model.
• If the path starts with a /, then it is an absolute path (the referenced data lookup is performed from the root object of the model). Otherwise, it is a relative path.
• Relative paths are concatenated with the binding path of the nearest ancestor control which has a binding context for the model. If the resulting path is still relative, this is repeated recursively until an absolute one is obtained.
• For JSON models, the path is split by the / sign and then the JSON object tree is traversed using the attribute names obtained from this split.

Concretely, in the case of ${}, the binding path itself is '' (an empty string). Using the rules above, this would be a relative path for the unnamed (default) model. As the path is empty, no attribute traversal is done (because there are no path components obtained after the path split).

Similarly, for named models, the ${MyModelName>} expression binding would have the same effect.