Show TOC

Data BindingLocate this document in the navigation structure

Use

To make programming easier for you with the MVC design, the framework for the model of an application provides you with basic class CL_BSP_MODEL, which you can use in your own model class as a class that passes on its properties. The model class represents the data context of your application and, as a result, receives a copy of the data (or references to the data) that are relevant for the view from the database model.

The model class provides:

  • The data used for the views, with the corresponding type and data Dictionary information.

  • Input conversions

  • Information about input errors that occurred for which data

A controller can instantiate a model class or even several model classes (see also Calling the Model Class Using the Controller). The controller has a list of all model instances, analogous to the list of subcontrollers.

The controller assigns unique IDs to each model instance.

Note

If you are using the MVC Design Pattern, you do not need to use the Application Class. Instead of the usual Application Class with purely page-based BSP applications, you should use controllers and model classes in the MVC environment.

Data binding is particularly important with HTMLB extension elements inputField and label (see also the documentation for these elements in the system). It is also implemented for HTMLB elements dropdownListBox, radioButtonGroup, checkbox, textEdit, and tableView.

A model class can either be designed quite simply or it can be used with more complex application cases.

Simple Model Class

Data binding is important for transmitting values for output data. Add the data that is required by the view to your model class as attributes. These attributes are all from the visibility range public and can be as follows:

  • Simple variables

  • Structures

  • Tables

In the most simple case, the model class has these attributes only and so can easily be used for data binding as part of a BSP application.

This type of simple model class provides the following functionality:

  • The controller can create a model instance and initialize the attributes, since they are public attributes.

  • The controller transmits a reference to the model instance to the view.

  • The data binding to the model is specified in the view for each view element using a path expression ( //…).

Example

A BSP application contains an input field that is implemented using HTMLB, in which users can write data.

model is defined as a page attribute. For the input field you can then write:

<htmlb inputField … value="//model/<Attribut>"

This ensures that the content of value is bound to the corresponding attribute of the model class.

The process flow is now as follows:

  1. The content of the attribute is assigned to the input field value using the above statement.

  2. This generates the ID from the model.

  3. Additional attributes are also generated, for example, one that determines whether fixed values exist.

  4. User input is transferred to the model class at the next request.

  5. Data conversions including connection to the Dictionary (conversion exists, for example) are automatically executed by the base model class.

    In the default case, if a conversion exit for a field exists in the ABAP Dictionary, this conversion exit is called. All data contained in the ABAP Dictionary structure for the field are available. If, however, separate setter/getter methods (see the following section) are written, the conversion exit can be switched off.

If necessary you can also add your own methods to your model class for further processing attributes.

Complex Model Class

It is possible that simple model classes are not sufficient for your requirements. This may be the case, for example, if you are working with generic data or if you need special methods for setting ( SET) and getting ( GET) attributes. You can therefore use these methods to determine your own implementations that are important for your specific application.

In these types of applications, the base class contains copy templates for the setter and getter methods: _SET_<Attribute> and _GET_<Attribute>. All of these templates begin with _. The naming conventions for the actual methods are as follows:

Naming convention for setter methods:

SET_<Attribut> for a field

SET_S_<Attribut> for a structure

SET_T_<Attribut> for a table

Naming convention for getter methods:

GET_<Attribut> for a field

GET_S_<Attribut> for a structure

GET_T_<Attribut> for a table

Example

An example of implementing a getter method for structure fields/structure attributes:

method GET_S_FLIGHT .

field-symbols: <l_comp> type any.

assign component component of structure flight to <_comp>.

value = <l_comp>.

if component eq 'CARRID'.

translate value to lower case.

endif.

endmethod.

The ABAP keyword assign component assigns the structure component component for the structured field flight (with reference type sflight) to the field symbol < l_comp>. The value of < l_comp> is output as follows: If the structure component component points to an airline ( CARRID), the name of the airline is translated in lowercase. If the structure component component points to a single flight connection ( CONNID), then some of the introductory zeros may be deleted.

As soon as a setter or a getter method is set, it is used automatically.

Data binding is automatically available because the name is the same. In method DO_HANDLE_DATA (see also Process Flow) of class CL_BSP_CONTROLLER2 all controllers automatically fill the form fields with data.

The path specifications for the model data have the following syntax:

  • Simple field attribute

    value="//<field name>"

  • Structure attribute

    value="//<structure name>.<field name>"

  • Table attribute

    value="//<table name>[<line index>].<field name>"