This section of the FAQ provides answers to ALV related questions.
(1) How to use attribute properties in the WD ALV component?
(2) How to setup bindings for application function editors (toolbar controls)?
(3) How to programmatically expand sub totals to a certain level?
(4) How to work with non validating actions?
(5) How to reuse the personalization data across multiple WD ALV instances?
The design of contexts is very important for the performance of large Web Dynpro ABAP applications. A large number of context nodes and attributes will reduce performance and increase memory requirement at runtime. Since a range of UI element properties provide the binding to a context attribute, the number of context attributes can exceed the number of UI elements many times over.
To prevent the implementation of large numbers of context attributes, as an alternative, the properties of the context attribute to which the primary property of the UI element is bound can be used to bind the UI element properties.
The primary property is especially important for a UI element. Other properties of the UI element can be dependent on the value of the context attribute to which the primary property is bound. Provided the UI element is available, the primary property is always the same, for example:
- The property value for the UI element InputField
- The property text for the UI element TextView
- The property checked for the UI element CheckBox
Some UI element properties can be bound directly to the context attribute of the associated primary property, which means a new context attribute does not have to be especially created.
The Web Dynpro ABAP framework enables the following UI element properties to be bound in this way:
- required (not relevant in WD ALV usage)
To use attribute properties in the WD ALV component, the DATA node mapped or propagated to the component has to be supplied with an internal table containing the properties for that specific DATA node. The internal table must be of type WDR_CONTEXT_PROP_FOR_NODE_TAB. The rows of that table must be of structure type WDR_CONTEXT_NODE_PROP_FOR_NODE. All attribute properties are of type WDY_BOOLEAN.
The following example shows how the attribute properties are set up for a DATA node mapped to a WD ALV instance:
To set up a binding for a column editor control in the WD ALV component referencing such an attribute property, the following syntax must be used:
The fieldname thereby denotes the identifier of the field resp. attribute in the mapped or propagated DATA node. The attribute_property specifies the property name to bind to, i.e. one of the following values from column Property:
|| Controls the read only state of a table cell. ABAP_TRUE if the cell should be read-only, ABAP_FALSE if it should be editable.
|visible||WDY_BOOLEAN|| Controls the visibility of a table cell. ABAP_TRUE if the cell should be visible, ABAP_FALSE if it should be invisible.
|enabled||WDY_BOOLEAN|| Controls the enabled state of a table cell. ABAP_TRUE if the cell should be enabled, ABAP_FALSE if it should be disabled.
The following code snippet shows how the bindings for all three properties are set up for a specific column editor.
If using attribute properties, it is also mandatory to provide the SALV_WD_TABLE_INDEX attribute (type SYTABIX) as additional attribute in the DATA node.
For further bakcground information regarding the attribute properties feature in the Web Dynpro ABAP Framework see also the official Web Dynpro ABAP developer documentation.
The application SALV_WD_TEST_TABLE_ATTRPR, which is officially released together with the actual WD ALV component implementation also shows the usage of attribute properties in a concrete sample application environment.
Each application function created in the configuration model of the WD ALV component is associated to an editor like for instance a Button, an InputField, a ToggleButton etc. At runtime these editors are represented or rather rendered as toolbar controls. Some of these application functions that you can insert into the toolbar cause data to change when the end-user triggers them, e.g. when the end-user places an input into an InputField or clicks a ToggleButton. Therefore these functions have to be linked to a context node of the application. To do this, an external context mapping to a context node named FUNCTION_ELEMENTS is defined. This context node is exposed via the public WD ALV interface controller. The application defines a suitable attribute or subnode for each function beneath this context node.
If the mapping to that FUNCTION_ELEMENTS node has been properly established, the application can bind properties of application function editors directly to the respective attributes in the mapped application context node. The following code snippet exemplarily outlines the creation of an application function and its editor in shape of a ToggleButton and the subsequent binding for its checked property.
Furthermore the application SALV_WD_TEST_TABLE_TOOLBR, which is officially released together with the actual WD ALV component implementation also shows the correct definition and handling of the FUNCTION_ELEMENTS node in a concrete sample application environment.
If the application has created one or multiple aggregation rules and has furthermore defined sub totals across more than one alphanumeric field, this will result in a multi level sub total hierarchy. The WD ALV API provides an opportunity to display and hide entries and sub totals across the table. To do this, the following method in the WD ALV Configuration Model can be leveraged:
VALUE Importing Optional Type I
The VALUE parameter thereby accepts the following values:
Please note that this approach only works, if the method IF_SALV_WD_FIELD_SETTINGS~SET_GROUP_AGGR_COLLAPSED has been set to ABAP_FALSE, which is the default in an WD ALV Configuration Model.
Subtotal levels are displayed graphically in the results row in the output: The lowest subtotal level 1 is represented by a bullet point beside the result, the next-highest is represented by two bullet points, and so on. By clicking on one of these symbols, the user displays or hides the entries that were used to create these results.
This ability to display the data records of a single result is not available via the WD ALV Configuration Model. You always display or hide entire subtotal levels with all entries. This is known as a homogenous drilldown.
The Web Dynpro for ABAP Franework supports the concept of validating (standard) and non-validating (sometimes also denoted as validation-independent) actions. In a standard Web Dynpro component that validation type is specified as a property of an action associated to a specific View. Standard, i.e. validating hereby means that an action and thus its associated action event handler is only executed if no error messages currently exist. Non-validating resp. validation-independent however means, that actions are executed even if error messages exist.
The WD ALV component works with the concept of so called application functions. Each of these application can be associated to an editor, which is at runtime then represented or rather rendered as a toolbar control. To react on events triggered by an application function, an application can register itself on the generic event entitled ON_FUNCTION, which is exposed via the public WD ALV component interface. Events fired by application functions are thereby currently always non-validating (validation-independent), i.e. they are always triggered, regardless if any error messages exist.
This means that the differentation between validating and non validating actions is currently not supported and can therefore not be specified via the WD ALV Configuration Model. The concept might be supported in future releases, but so far there are not definitive plans in that direction.
The standard scenario is that an application simply embeds the WD ALV component via a Web Dynpro component usage into its own application component. That specific WD ALV component instance then can be further personalized at runtime via the Settings UI, either by an administrator or by an end-user. In this context the component allows the management of so called views. A view is an entity identified by a unique name and comprises the whole set of configurable options that can be personalized at runtime via the Settings UI. The Settings UI itself provides options dealing with the management of those views.
By default, if a view is saved, the specific WD ALV component instance is automatically associated to a so called configuration key. This key is used to uniquely identify the personalization data in shape of the stored views, which have been persisted for that WD ALV instance. The key is composed of the following components:
- USAGE PATH: The location of the current application in the Web Dynpro application hierarchy.
- ALV_COMPONENT_USAGE: The name of the component used in the embedding application component.
To now use that personalization data across the borders of a single Web Dynpro application component or Web Dynpro View, a different approach has to be pursued. Therefore a stable configuration key has to be provided. This is necessary to achieve that the key is not generated automatically on-the-fly by the WD ALV component itself. For this purpose the WD ALV component provides a dedicated Personalization API. This API is part of the public SALV_WD_TABLE component interface. The relevant method is called GET_CONFIG_API. This API method is leveraged to specify an application specific configuration key. The key must fulfill the following conditions:
- It identifies the application in which the WD ALV output is displayed. The field USAGE_PATH from _S_PARAM_OUT_ can be used for this purpose.
- It identifies the ALV output within the application. If multiple ALV outputs are displayed in the application, it must be possible to distinguish them from one another. To do this, the field ALV_COMPONENT_USAGE can be used, which returns the component usage for the individual WD ALV output.
- It identifies the structure that is displayed in the ALV output with SET_DATA or via reverse context mapping and bind_table. To do this a free identifier in shape of any unique character string can be used for instance.
If these three components are connected to one another, a key that identifies a structure sufficiently can be generated. This way, a view can be assigned uniquely.
The following example shows the steps in an example method SET_ALV_CONFIG_ID, that are required for generating and assigning the configuration key.