Content
- Tags:
Data Binding
Introduction
This example discusses how to use BTL and other parts of the Backbase Client Framework to implement data binding.
Prerequisites and Intended Audience
This example is intended for anyone interested to understand the Backbase data binding mechanism. To work through this example you need the Backbase Client Framework 4.1.2, and beginner level experience of BTL and object-oriented development.
Overview
Before data can be displayed by a widget such as the suggestBox or listGrid, the data first
needs to be represented as an object. This process is referred to as data binding, and is one of the
features of the Backbase Client Framework. BTL contains several elements to implement data binding, as will be
demonstrated in this example.
Creating the Data Object
As mentioned, for data binding a data object first needs to be created. With the Backbase Client Framework, this data object is created
by the dataSource element. The dataSource element offers an interface for widgets that need to
access data. By offering one interface, the dataSource can take the responsibility of handling
different types of data. The dataSource processes the data and builds the data object. This means
that widgets that display the data do not have to know about different data types, but only about
the API of the dataSource.
The dataSource is not complete without data. One of the ways of specifying data is to use the
dataContainer element. As the name dataContainer describes, it is a container for data. Any child
elements of the dataContainer are not parsed by the engine, preventing unnecessary overhead while
creating a page containing a dataContainer.
Listing: dataSource with dataContainer
-
please note that this code fragment is not intended to work as is.
dataSource Behaviors
There are different ways to access, display, and interact with data:
- Data is available in different formats. Two examples are Extensible Markup Language (XML) and JavaScript Object Notation (JSON).
- Data can either be available on a server (this is preferable with large datasets) or on the client.
- Data often needs to be sorted, other times data may be filtered, and there are cases in which you would not want to show all the data at the same time, but in smaller parts (a mechanism called paging).
BTL offers three out-of-the-box
behaviors for the dataSource that deliver an implementation for the common use cases:
| features | description | |
|---|---|---|
| staticData |
|
Simple behavior that can be used when no modification of data or view is necessary. |
| localData |
|
To be used when the data will be completely available on the client. |
| remoteData |
|
When the dataset is too big to send to the client this behavior can incrementally get data from a server. |
Table: Overview of out-of-the-box behaviors
Static Data
The staticData behavior is the simplest behavior. The data cannot
be sorted, filtered, or edited. The data
is completely present on the client, but as there are no other features, widgets to which the data is bound are rendered faster.
An example implementation is shown in the following listing:
Listing: dataSource with the staticData behavior
Next to the behavior, the dataSelect attribute has been added. This attribute
is part of the staticData behavior. The value should be an XPath query. The
query defines the root element of the XML data source.
The value shown in the listing is the default value, which is also used if the attribute is not set.
Showing the Data in a Widget
Any widget that is bound to data should inherit from dataObserver. dataObserver contains
attributes, properties and methods that are used for data binding.
| type | description | |
|---|---|---|
| dataSource | attribute | The name of the dataSource from which the dataObserver will get the data. |
| dataSource | property | The reference to the dataSource from which the dataObserver will get the data. |
| dataUpdate | method |
This method is called by the dataSource when the dataObserver is registered
to the dataSource and whenever the data in the dataSource is updated. It
should be used to get the data from the dataSource in order to create the view of the
dataObserver.
|
Table: dataObserver attributes, properties and methods
Because each widget that inherits from dataObserver has a different view, the
dataUpdate method has to be overridden, and should contain custom code to update
the view. The following listing shows such an implementation:
Listing: the dataUpdate method
The dataUpdate method has two arguments:
-
action- a string, the value of which depends on what is supported by the particulardataSourcebehavior. Possible actions can becreate,read,updateordelete. -
records- contains an array of identifiers of records that have been updated. For example, when the action isread, the array contains the identifiers of all the records that should be visible. In the case of thestaticDatabehavior, it contains the identifiers of all records in thedataSource.
The btl.dataSource.getValue function is used to retrieve a value in a record.
The first argument is the reference to the dataSource that is observed. The second
argument is the unique identifier of a record, which is usually one item in the
records array. The third argument is the query string to query the data in the record.
In the example, the name field of the XML data will be queried.
Below is the listing for a custom widget that contains this dataUpdate method. The
widget represents an unordered list that gets its contents from the dataSource. The
dataSource contains some simple data.
Listing: a data bound widget
Closure
This example page has described and demonstrated how the Backbase Client Framework handles data binding. Below is the result of the code in the final listing:
Live Demo
Additional Resources
For more information, please refer to the following:
- Remote Data Binding (example)
- Introduction to the listGrid (example)
- Introduction to the treeGrid (example)
- Application Development Guide (PDF)
- Backbase Client Framework Reference (CHM)