To retrieve data from the model for visualization in the UI, the controls have to be bound to the model by means of a binding path. The control itself, all properties of controls, and all multiple aggregations can be bound to a model.
For binding controls to the model, several binding types exist:
Element binding allows to bind elements to a specific object in the model data, which will create a binding context and allow relative binding within the control and all of its children. This is especially helpful in master/detail scenarios.
Property binding allows properties of the control to get automatically initialized and updated from model data. You can only bind control properties to model properties of a matching type, or you use a formatter function or datatype to convert the data as needed.
Aggregation binding can be used to automatically create child controls according to model data. This can be done either by cloning a template control, or by using a factory function. Aggregations can only be bound to lists defined in the model, that is, to arrays in a JSON model or a collection in the OData model.
The model has a default size limit to avoid too much data being rendered on the UI. This size limit determines the number of entries used for the aggregation bindings. The default size limit is 100 entries.
This means that controls that don't support paging or don't request data in chunks (e.g. sap.m.ComboBox) only show 100 entries even though the model contains more items.
To change this behavior, you can set a size limit in the model by using oModel.setSizeLimit.