Using data source controls
Table of contents
- Introduction
- Using an EPiServer Data Source control
- Element attribute versus query parameter
- Creating your own Data Source controls
- Mapping between Control properties and Data Source parameters
Introduction
One of the more influential groups of controls included in EPiServer CMS are the Data Source controls.
One of the major benefits of using these controls is that they minimize the need of
codebehind for day to day operations involving reading data and populating various
lists, trees etc.
The new controls supports all or a few of the select, insert, update and delete operations.
Some benefits of using the controls are:
- Minimized need of plumbing code in code-behind
- Built-in support for select, insert, update and delete
- A contract that fits many of the built-in .NET controls and third-party controls
The Data Source controls can be categorized as Hierarchical and Tabular or both depending on how they can deliver data. Hierarchical data source controls expose data in a hierarchical fashion (parent – child) and can be used for tree views such as the TreeView and Menu controls in ASP.NET. Most controls though, serve data in tabular fashion which can be used for listing controls such as the Repeater, DataList, GridView etc. An important difference between hierarchical and tabular data sources are that hierarchical data sources are read only whereas the tabular data sources can support inserting, updating and deleting as well. The following controls implement the IHierarchicalDataSource interface and can generate data for tree view controls or menus:
- PageDataSource
- CategoryDataSource
- FileSystemDataSource
To create your own tabular Data Source controls you are advised to use the base class GenericDataSource.
Using an EPiServer Data Source control
The controls in EPiServer CMS are built and designed with ease of use in mind. There should be very little need of adding your own code behind to these classes as they are intended to be used in markup rather than coded against or inherited from. If you do need additional functionality we recommend that you inherit from the GenericDataSource control and create classes that suit your needs.
The Data Source controls work as any standard control in an .aspx page. Please refer to the templates and demo site packages available from EPiServer World for examples and information on how to implement the different controls shipped with EPiServer CMS.
Element attribute versus query parameter
When populating a Data Source you will usually use a QueryStringParameter to read a selection of objects from the database (there is also a base class for reading objects from the ObjectStore, which means ObjectStoreDataSource). It is possible to define a value for a member of the object both as an attribute in the asp element and as a parameter in the query string. In this case the query string definition will take precedence over the asp attribute.
Consider the following example:
<EPiServer:CategoryDataSource
runat="server"
ID="CategoryData"
IncludeRootCategory="true">
<SelectParameters>
<asp:QueryStringParameter
Name="ID"
QueryStringField="ID"
Type="Int32" />
<asp:QueryStringParameter
Name="IncludeRootCategory"
QueryStringField="IncludeRootCategory"
Type="Boolean"
DefaultValue="false" />
</SelectParameters>
</EPiServer:CategoryDataSource>
Since IncludeRootCategory is defined twice (being set to true in the tag definition and false in the QueryStringParameter), the value set in the query string parameter will be used. If no query string parameter named “IncludeRootCategry” is specified, it is default value will be used, in this case “false”.
For more information on how to use parameters with Data Source Controls, please read Microsoft’s article Using Parameters with Data Source Controls.
Note that certain words are not recommended to use as parameter names for http requests. Consider the word “ID”.
If you try to use this as a parameter name for one of your http requests it will cause a conflict since
the word “ID” is used to identify aspx pages in EPiServer.
A line like this:
<asp:QueryStringParameter Name="ID" QueryStringField="ID" type="Int32" />
would conflict with the page ID. If the page for example had an ID of 200, every call to the CategoryDataSource would try to fetch categories with a parent ID of 200.
Changing the line to the following would solve this issue:
<asp:QueryStringParameter Name="ID" QueryStringField="CategoryID" type="Int32" />
Creating your own Data Source controls
Designing your own Data Source controls is simply a matter of inheriting from the class GenericDataSource. The following lines of code show how the TabDefinitionDataSource is defined. Note that there is very little code involved to get access to the basic functionality.
public class TabDefinitionDataSource :
GenericDataSource<TabDefinition, TabDefinitionCollection, int>
{
protected override TabDefinition CreateItem(List<TabDefinition> items)
{
return new TabDefinition();
}
protected override List<TabDefinition> ListItems()
{
return ToList(TabDefinition.List());
}
protected override TabDefinition LoadItem(int key)
{
return TabDefinition.Load(key);
}
protected override void SaveItem(TabDefinition item)
{
item.Save();
}
protected override void DeleteItem(TabDefinition item)
{
item.Delete();
}
}
As you can see, GenericDataSource<TObject, TCollection, TKey> is a class with three type parameters:
Name | Explanation | Example |
---|---|---|
TObject | The business object type | TabDefinition |
TCollection | A collection type that holds objects of type TObject | TabDefinitionCollection or List<TabDefinition> |
TKey | The data type of the primary key | int |
Business Objects
Before you can create your Data Source control type, you need to have a class, your business object,
that handles the data that you wish to present. In the sample above the class used for this is
TabDefinition. This class is responsible for reading and saving data
from the database.
If you have no need to implement any specialized behavior in your collection of business objects, you can use the generic List provided by the .NET Framework as described in the short sample below:
...
...
public class MyObjectDataSource :
GenericDataSource<MyObject, List<MyObject>, int>
{
...
...
Mapping between control properties and Data Source parameters
A common way to limit a result set of a data source control is to provide it parameters in the SelectParameters collection (see Parameter). This is supported by most of the EPiServer data source controls by allowing certain control properties to be overridden by a parameter value. The properties that can be specified using Parameters for a given EPiServer data source control are listed below.
Following is a list of data source controls and the corresponding properties:
-
PageDataSource
Property Type AccessLevel EPiServer.Security.AccessLevel PageLink EPiServer.Core.PageReference PageLinkProperty String IncludeRootPage Bool -
SearchDataSource
Property Type AccessLevel EPiServer.Security.AccessLevel PageLink EPiServer.Core.PageReference PageLinkProperty String IncludeRootPage Bool OnlyWholeWords Bool SearchQuery String SearchFiles Bool SearchLocations String MainCatalog String MainScope String MaxAllowHits Integer -
CategoryDataSource
Property Type IncludeRootCategory Bool -
FileSystemDataSource
Property Type -
LanguageDataSource
Property Type -
PageDefinitionDataSource
Property Type Dynamic Bool PageTypeID Integer -
PageDefinitionTypeDataSource
Property Type ID Integer -
PageVersionDataSource
Property Type PageLink EPiServer.Core.PageReference LanguageBranch String -
TabDefinitionDataSource
Property Type ID Integer -
MembershipUserDataSource
Property Type UserName string -
SoftLinkDataSource
Property Type PageLink EPiServer.Core.PageReference ListReferencing Bool
See also
Last updated: Mar 31, 2014