TRepeater displays its content repeatedly based on the data fetched from
{@link setDataSource DataSource}.
The repeated contents in TRepeater are called items, which are controls and
can be accessed through {@link getItems Items}. When {@link dataBind()} is invoked,
TRepeater creates an item for each row of data and binds the data row to the item.
Optionally, a repeater can have a header, a footer and/or separators between items.
The layout of the repeated contents are specified by inline templates.
Repeater items, header, footer, etc. are being instantiated with the corresponding
templates when data is being bound to the repeater.
Since v3.1.0, the layout can also be specified by renderers. A renderer is a control class
that can be instantiated as repeater items, header, etc. A renderer can thus be viewed
as an external template (in fact, it can also be non-templated controls).
A renderer can be any control class.
- If the class implements {@link \Prado\IDataRenderer}, the Data
property will be set as the data row during databinding. Many PRADO controls
implement this interface, such as {@link TLabel}, {@link TTextBox}, etc.
- If the class implements {@link IItemDataRenderer}, the ItemIndex property will be set
as the zero-based index of the item in the repeater item collection, and
the ItemType property as the item's type (such as TListItemType::Item).
{@link TRepeaterItemRenderer} may be used as the convenient base class which
already implements {@link IDataItemRenderer}.
The following properties are used to specify different types of template and renderer
for a repeater:
- {@link setItemTemplate ItemTemplate}, {@link setItemRenderer ItemRenderer}:
for each repeated row of data
- {@link setAlternatingItemTemplate AlternatingItemTemplate}, {@link setAlternatingItemRenderer AlternatingItemRenderer}:
for each alternating row of data. If not set, {@link setItemTemplate ItemTemplate} or {@link setItemRenderer ItemRenderer}
will be used instead.
- {@link setHeaderTemplate HeaderTemplate}, {@link setHeaderRenderer HeaderRenderer}:
for the repeater header.
- {@link setFooterTemplate FooterTemplate}, {@link setFooterRenderer FooterRenderer}:
for the repeater footer.
- {@link setSeparatorTemplate SeparatorTemplate}, {@link setSeparatorRenderer SeparatorRenderer}:
for content to be displayed between items.
- {@link setEmptyTemplate EmptyTemplate}, {@link setEmptyRenderer EmptyRenderer}:
used when data bound to the repeater is empty.
If a content type is defined with both a template and a renderer, the latter takes precedence.
When {@link dataBind()} is being called, TRepeater undergoes the following lifecycles for each row of data:
- create item based on templates or renderers
- set the row of data to the item
- raise {@link onItemCreated OnItemCreated}:
- add the item as a child control
- call dataBind() of the item
- raise {@link onItemDataBound OnItemDataBound}:
TRepeater raises an {@link onItemCommand OnItemCommand} whenever a button control
within some repeater item raises a OnCommand event. Therefore,
you can handle all sorts of OnCommand event in a central place by
writing an event handler for {@link onItemCommand OnItemCommand}.
When a page containing a repeater is post back, the repeater will restore automatically
all its contents, including items, header, footer and separators.
However, the data row associated with each item will not be recovered and become null.
To access the data, use one of the following ways:
- Use {@link getDataKeys DataKeys} to obtain the data key associated with
the specified repeater item and use the key to fetch the corresponding data
from some persistent storage such as DB.
- Save the whole dataset in viewstate, which will restore the dataset automatically upon postback.
Be aware though, if the size of your dataset is big, your page size will become big. Some
complex data may also have serializing problem if saved in viewstate.