How to use attribute properties in the WD ALV component?

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) read_only visible enabled 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:

data lr_node type ref to if_wd_context_node. lr_node = wd_context->get_child_node( 'DATA' ).

data: ls_attribute_properties type wdr_context_prop_for_node, lt_attribute_properties type wdr_context_prop_for_node_tab.

data: l_element type i,

l_elements type i.

l_elements = lr_node->get_element_count( ).

do l_elements times. add 1 to l_element. clear ls_attribute_properties. ls_attribute_properties-element_index = l_element. do 3 times. case sy-index. when 1. ls_attribute_properties-attribute_name = 'CARRID'. when 2. ls_attribute_properties-attribute_name = 'CONNID'. when 3. ls_attribute_properties-attribute_name = 'FLDATE'. endcase. ls_attribute_properties-visible = abap_true.

ls_attribute_properties-read_only = abap_true. ls_attribute_properties-enabled = abap_true.

insert ls_attribute_properties into table lt_attribute_properties. enddo. enddo. lr_node->set_attribute_props_for_node( lt_attribute_properties ).

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: fieldname:attribute_property 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:

Property

Type

Description

read_only

WDY_BOOLEAN

Controls the read only state of a table cell. ABAP_TRUE if the cell should be readonly, 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.

data ls_column type salv_wd_s_column_ref. data lr_input_field type ref to cl_salv_wd_uie_input_field.

lr_input_field->set_visible_fieldname( |{ ls_column-id }:{ 'VISIBLE' }| ). lr_input_field->set_enabled_fieldname( |{ ls_column-id }:{ 'ENABLED' }| ). lr_input_field->set_read_only_fieldname( |{ ls_column-id }:{ 'READ_ONLY' }| ).
Important Note: 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. Table of Contents

How to setup bindings for application function editors (toolbar controls)?

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.

data lr_function type ref to cl_salv_wd_function. lr_function = lr_functions->create_function( 'MYTOGGLEBUTTON' ).

lr_toggle_button

type ref to cl_salv_wd_fe_toggle_button.

create object lr_toggle_button exporting checked_elementname = 'CHECKED'. lr_toggle_button->set_text( 'MYTOGGLEBUTTON' ). lr_toggle_button->set_image_source( 'ICON_FLIGHT' ). lr_toggle_button->set_checked_image_source( 'ICON_FLIGHT' ). lr_function->set_editor( lr_toggle_button ).
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. Table of Contents

How to programmatically expand sub totals to a certain level?

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: IF_SALV_WD_FIELD_SETTINGS~SET_EXPAND_LEVEL Parameters: VALUE Importing Optional Type I The VALUE parameter thereby accepts the following values:

Value

Description

Displays all rows for all sub total levels.

Hides all data rows. The result rows of sub total level 1 and higher remain visible.

Hides the result rows of the sub totals level 1. Ony the result rows for sub total level 2 and higher (if applicable) remain visible.

Collapses all total and sub total nodes. Only the total rows and sub totals of level 1 remain visible.

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. Note: 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. Table of Contents

How to work with non validating actions?

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. Nonvalidating 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. Table of Contents

How to reuse the personalization data across multiple WD ALV instances?

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.

method SET_ALV_CONFIG_ID. [ ... ]

data: l_ref_if_controller type ref to iwci_salv_wd_table,

lr_node own_key

type ref to if_wd_context_node, type string.

*... Get RELEVANT NODE of the APPLICATION CONTEXT lr_node = WD_THIS->APPL_get_data_node( ).

*... Determine name for Key depending on THE APPLICATION CONTEXT

OWN_KEY = 'ALV1'.

*... SET NODE of THE APPLICATION CONTEXT l_ref_if_controller->set_data( r_node_data = lr_node ).

[ ... ]

*... Create configuration key consisting of usage path, component usage, own key data: ls_param_out type if_salv_wd_table=>s_type_param_config_out, ls_param_in l_key l_key_32 type if_salv_wd_table=>s_type_param_config_in, type string, type string.

ls_param_in-action = if_salv_wd_table=>key. ls_param_out = l_ref_if_controller->get_config_data( ls_param_in ).

concatenate ls_param_out-usage_path ls_param_out-alv_component_usage own_key into

l_key separated by '&'.

*... Hash configuration key to unique key of 32 chars length try. l_key_32 = cl_rsmds_hash_utilities=>to_hash_c32( l_key ). catch cx_rsmds_input_invalid cx_rsmds_input_invalid_type. endtry.

[ ... ]

*... Set new configuration key ls_param_in-action = if_salv_wd_table=>set.

ls_param_in-config_key-config_type = '08'. ls_param_in-config_key-config_id = l_key_32.

l_ref_if_controller ->get_config_data( ls_param_in ).

[...] endmethod.