Web Dynpro ABAP Integrating Forms

For Web Dynpro user interfaces, forms can be created and used in the context of SAP Interactive Forms by Adobe. For efficient and straightforward development of the user interface, you can integrate the Adobe LiveCycle Designer tool with editor and the Adobe UI elements into the development workbench.

As of NetWeaver 7.0 (NW 7.0) SPS10 forms can be integrated using Zero Client Installation (ZCI).

As of NetWeaver 7.0 SPS10 we strongly recommend you use ZCI forms with an XML interface only. Because additional central features have been added in subsequent SPs (input help and dropdown list boxes), we generally recommend that you always use the most up-to-date Support Package for Web Dynpro ABAP.

We recommend that you always use forms with an XML interface. Existing forms with an ABAP Dictionary-based interface can be used as print forms. We do not recommend their use as interactive forms.

There are several ways of using the solution SAP Interactive Forms by Adobe:

● Print scenario

This scenario is used for printing and displaying forms. Unlike in the interactive scenario, only non-input-enabled PDF forms (PDF-based print forms) are used here.

● Interactive scenario

With this scenario, forms containing input-enabled elements are created and edited.

We recommend you use interactive forms only after carefully checking the requirements of your application. Interactive forms should only be used if a PDF-based form really does have advantages over a normal Web Dynpro view. This can include for instance scenarios in which paper-based processes are to be replaced or complimented by an online scenario with exactly the same form layout. Other cases can be applications where, in addition to the online scenario the same form is needed in static form for printing, archiving, sending by e-mail, or for other purposes.

● Offline scenario

Forms that already exist in the system as MIME objects in the MIME Repository are stored, or are uploaded (see File Upload) here within a Web Dynpro application for display purposes.

● Scenario with digital signatures

See Digital Signatures in Form Integration

The procedure for creating or using the relevant forms is largely the same for the first two scenarios. There is however an essential difference with ACF forms when you call applications: When you first call an interactive form a CAB file containing a plug-in for the locally installed Adobe Reader is automatically loaded from the server. This Active Components Framework (ACF) allows you to process form contents on your local computer. However, the ACF is not required for displaying or printing a form.

Zero Client Installation (ZCI) and Active Component Framework (ACF)

Interactive forms in the ISR framework are part of ZCI. They can be used as of SAP NetWeaver SPS 10 at runtime in Web Dynpro for ABAP based on Zero Client Installation (ZCI). To enable this, the forms must contain special scripting, which you insert when you create new forms in Form Builder.

Until now, you needed to install Active Component Framework (ACF) on the front-end PC to use interactive forms. As of SAP NetWeaver 7.0 SPS10, ZCI enables you to use interactive forms in Adobe Reader without any additional plug-ins. ACF is therefore no longer required for interactive forms. You can use a report to make any interactive forms created with an older version of SAP NetWeaver ZCI-compliant. For more information, see Check and Update Functions with the Report FP_CHK_REPORT.

UI Element InteractiveForm

For Adobe integration, the InteractiveForm interface element in category integration is provided in the Web Dynpro View Designer.

Prerequisites

See Form Integration Prerequisites.

Connection Tests

For ZCI run report FP_CHK_REPORT.

For ACF execute program FP_PDF_TEST_00 to ensure that the ADS was configured correctly. If the configuration is correct, the out put of the test program will be the version number of the installed ADS.

For information about potential errors see Error and Problem Analysis and Adobe Document Services Problem Analysis Scenarios. More information: SAP Note 999998.

Creating Web Dynpro Application Using Forms

Forms can be created and maintained independently of Web Dynpro applications using the Form Builder (transaction SFP). For information on creating forms and how to handle the Form Builder, see Form Design with the Form Builder. Note that interfaces that are compatible with Smart Forms are not supported in Web Dynpro ABAP. In principle, you can integrate a form in each view in any component, though it is often better to create a separate view to integrate it.

The individual steps involved in creating or using a form are described in the following:

Integrating PDF Forms in a Web Dynpro application.

Interactive Form Use

You can find e-learning tutorials with code examples of integrating ACF forms in Web Dynpro applications in SDN. These tutorials were created using NW7.0 SPS6.

Restrictions

The integration of forms (and further active controls) into Web Dynpro ABAP popups is not supported.

For further limitations, see SAP Note 1098009.

Example

In the system in component WDR_TEST_ADOBEYou can find a complex test application for various scenarios that can arise when integrating forms using ZCI.

Notes

SAP Notes on SAP Service Marketplace

Number	Short Text
942506	Classification of forms by xACF and ZCI
766191	Active Component Framework Installation
999998	Error analysis for Web Dynpro ABAP Adobe integration
846952	Removing ACF from Client PC
955795	New creation of Web Dynpro ZCI forms in Form Builder
834573	Interactive Forms based on Adobe sw:Acrobat/Reader version
947675	ISR / Adobe: New layout type ZCI as of ERP 2005, SP 5
940637	OFFI: SetMerge Template for Adobe Template Designer
944954	Pre-assigning interactive forms with script
978037	Converting an ACF-based UI element to ZCI

Prerequisites for Form Integration Web Dynpro ABAP Integrating Forms

General Prerequisites

SAP NetWeaver AS System with Adobe Document Services (ADS)

To test the connection to ADS, run report FP_PDF_TEST_00. Version information about your ADS will be displayed.

If this test is successful, run report FP_TEST_00. Select a printer and select the option for the print preview. The Adobe Viewer appears and displays a simple form.

Language Settings

To display the form is displayed in the language required, you have to specify a combination of language and locale (country) as well as provide the necessary translations. The logon language of the system is used as the language. You can specify the country in your user profile (transaction SU52) on tab page Parameters. Enter UCN as the Parameter ID and enter the short code of the required country as the Parameter Value (use the notation in the second column of table T005). Then save your entries.

ZCI

System Prerequisites

● SAP NetWeaver NW7.0 SPS10 or higher

● SAPGUI Release 6.40 Support Package Level 20 or higher (see SAP Note 940637).

● Adobe LiveCycle Designer 7.1, support package level 1

Prerequisites for ZCI Forms

● Adobe Reader Version 7.x with x >= 08

ZCI and HTTPS require Adobe Reader 8.1

● Adobe Designer, version 7.1 SP 1 only

GUI patch level 20 must be installed.

● InteractiveForm properties:

○ For the interaction the enabled property in the Web Dynpro ABAP View Designer InteractiveForm UI element must be set to true.

○ The property displayType differentiates between ZCI (choose Native) and non-ZCI (choose ACF)

● Form designer (transaction SFP)

○ The Layout Type for properties is ZCI Layout

○ In the form use the Web Dynpro Native library.

○ In the form insert a ZCI script using Utilities ® Insert Web Dynpro Script.

You can assign this to the form.

Afterwards you can see the entry ContainerFoundation_JS z in the Hierarchy View in the Designer.

You may have to update the template used. More information: Check and Update Function with Report FP_CHK_REPORT.

ACF

● SAP NetWeaver AS System with Adobe Document Services (ADS)

Details on installation on the SAP Service Marketplace under the quick link: /installNW70.

Notes on importing licenses are available in the Configuration Guide.

To test the connection to ADS, run report FP_PDF_TEST_00. Version information about your ADS will be displayed.

If this test is successful, run report FP_TEST_00. Select a printer and select the option for the print preview. The Adobe Viewer appears and displays a simple form.

● Adobe Reader (>= 7.0) must be installed on your local computer (see SAP Note 834573)

Refer also to:

Integrating a PDF Form in a Web Dynpro Application Web Dynpro ABAP Integrating Forms

This chapter describes the procedure for using a PDF form in a Web Dynpro application with the various scenarios.

Form Integration for the Various Scenarios

Scenario	Procedure
Print Interactive	Integrating (Interactive) Forms
Offline	Integrating Existing Forms
Digital Signatures	Digital Signatures in Form Integration

Form Data in XML Format

In the procedure for the print scenario and the interactive scenario, only the two properties templateSource and dataSource of InteractiveForm were bound to the view context. The templateSource property contains information about the form template, while the context node, to which the dataSource property was bound, contains the values to be displayed in the form as individual Web Dynpro context attributes.

You can store or process the values of the form, completed at runtime by user input, in XML format. To do this, you have to include an additional attribute of type XSTRING in the view context. You then bind the pdfSource property of the UI element InteractiveForm to this context attribute (see offline scenario).

The XML representation of the PDF values can be read and processed here. Using a suitable template and this XML data, you can create a complete PDF again at a different point.

The transfer of form data from an XSTRING attribute, whose contents originate from the back end, into separate attributes of a Web Dynpro context node is not supported.

Inserting (Interactive) Forms Web Dynpro ABAP Integrating Forms

Use

As there is very little difference between the print scenario and the interactive scenario for inserting a form in a Web Dynpro application, the procedure for both scenarios is provided together below.

Forms with static content, such as PDF-based print forms, can be used to display or print data in Web Dynpro applications.

In the case of interactive forms, you can reuse user entries stored in the Web Dynpro context for your own Web Dynpro application.

In scenarios where the templateSource/dataSource are filled, the form can only be created if an ADS is available. On the other hand, the pdfSource property is ignored in this case. For the properties enabled and readOnly, note the following:

● If enabled is set, the form is displayed via the ACF.
If readOnly is set too, no entries or changes can be made in the form.

● If enabled is not set, the form is displayed without the ACF, and the readOnly setting is ignored.

Procedure

1. In the Web Dynpro explorer, create a view for your component or select a view to which to add the form.

2. In the view context, create the node with attributes that will be bound to the form later.

3. In the view, drag the InteractiveForm UI element from the integration category to the Layout Designer.

4. For the templateSource property, enter the name of the selected form.

You can select an existing form (via F4, for example) or enter a name to create a new form. Based on the interface of the selected form, a context node with attributes is automatically created for the InteractiveForm UI element. The dataSource property of the UI element is automatically bound to this context node.

If you are creating a new form, double-click the name.

...

a. The dialog box that now appears informs you that you have to specify an interface before you can create the new template. At this point, you can either use an existing interface or create a new one adapted to suit your Web Dynpro view. To create a new interface, enter a name and choose Context. Since the creation process is connected to the view you are processing, the context of this view is provided for the selection of a suitable node.

b. Choose the context node created in step 2 and close the dialog box.

c. In the next two dialog boxes, save a new interface and a form that uses this interface, each as a separate transport object. Do not save the view until the third dialog box appears.

d. You now go to Form Builder, where you can design the new form. To begin with here, you can have the basic framework of your form generated by choosing Generate Data View Using Fields.
When designing the form layout, note the translation link for forms.

Based on your selected Web Dynpro context, an XML schema is created for the new interface, which is available to the new form for data selection.

e. Save and activate your form in Form Builder (objects of type SFPF and SFP1).

5. Once you have finished designing the form, switch to the editing screen for the Web Dynpro view.

If you select the InteractiveForm UI element in the view layout, you will see that view context node has been automatically connected with the form or relevant interface.

6. Specify whether the form is a PDF-based print form or an interactive form.

○ If it is a non-interactive form usage, that is. the form is a PDF-based print form, make sure that the enabled property is not selected in the property table. This is the default setting.

○ If it is an interactive form usage, activate the enabled property in the property table. Note the various points that need to be observed during interactive usages.

7. After filling the created context structure – for example using a suitable supply function – and inserting it into the window navigation, you can activate and test an application.

Subsequent Changes to the Web Dynpro Context

To offer new elements in the data view for the form, you first need to enhance the relevant Web Dynpro context accordingly. You do this, as usual, in the context editor of the Web Dynpro Explorer. Triggering forwards navigation on the InteractiveForm UI Element takes you back to Form Builder. The XML schema is automatically adjusted, together with the data view in Form Builder.

If you used an existing templateSource for the form integration and its interface is not based on an XML schema, you cannot add any further data fields subsequently.

Note that other forms may have used or be using your interface. Check carefully before changing an interface.

Result

In the form displayed in the Web Dynpro application, you can perform the usual Adobe functions by choosing the relevant buttons, such as Print or Save a Copy.

Example

You can find a simple example component for the interactive scenario in the system in the SWDP_TEST package, under WDR_TEST_IA_FORMS.

Inserting Existing PDF Forms (MIME Objects) Web Dynpro ABAP Integrating Forms

Use

Forms that are stored in systems as MIME objects in the MIME repository with MIME type application/pdf can be integrated and displayed in a Web Dynpro application.

To do this, bind the pdfSource property to a context attribute of type XSTRING. In this case therefore, neither the templateSource nor the dataSource are set.

In scenarios where only the pdfSource is set, the properties enabled and readOnly are ignored. The form can then be displayed for printing (and is displayed without the ADS or the ACF).

Using the method call described below, the PDF document can be made ready for input, but there is no context binding. Instead, the changed document is retrieved from the pdfSource and processed in the specific application.

Prerequisites

You need to store your form in the MIME repository. The simplest way to do this is to import the form to your Web Dynpro component by choosing Create ® MIME Object ® Import.

The imported PDF appears in your component’s object list under MIMEs.

Example:

Procedure

...

1. In the Web Dynpro explorer, create a view for your component or select a view to which to add the form.

2. In the view context, create the context attribute that will be bound to the form later, and select XSTRING.

3. In the view, drag the InteractiveForm UI element from the integration category to the Layout Designer.

4. Go to the methods for your view and change WDDOINNIT by adding coding to the method, such as the coding below:

method WDDOINIT . data: Elem_Context type ref to If_Wd_Context_Element, Stru_Context type If_View=>Element_Context , Item_STATIC_PDF like Stru_Context-STATIC_PDF. * get element via lead selection Elem_Context = wd_Context->get_Element( ). DATA: mr TYPE REF TO if_mr_api, lurl TYPE string. * get name of component data: l_component type ref to if_wd_component, l_component_info type ref to if_wd_rr_component, l_name type string. l_component = wd_comp_controller->wd_get_api( ). l_component_info = l_component->get_component_info( ). l_name = l_component_info->get_name( ). * get mime object mr = cl_mime_repository_api=>get_api( ). call method CL_WD_UTILITIES=>CONSTRUCT_WD_URL( exporting APPLICATION_NAME = l_name importing OUT_LOCAL_URL = lurl ). concatenate lurl '/' 'popup.pdf' into lurl. mr->get( EXPORTING i_url = lurl IMPORTING e_content = Item_Static_Pdf ). Elem_Context->set_Attribute( exporting Name = `STATIC_PDF` Value = Item_Static_Pdf ). endmethod.

Here, you only need to specify the name of your MIME object, popup.pdf in this example.

You can also receive the MIME object by inserting the path manually:

DATA: mr TYPE REF TO if_mr_api, content TYPE xstring. mr = cl_mime_repository_api=>get_api( ). mr->get( EXPORTING i_url = 'sap/bc/webdynpro/sap/zhvg_adobe2/popup.pdf' IMPORTING e_content = content ).

5. In the properties table for InteractiveForm, bind the pdfSource to the context attribute created in step two.

6. After filling the created context structure – for example using a suitable supply function – and inserting it into the window navigation, you can activate and test an application.

Digital Signatures in Form Integration Web Dynpro ABAP Integrating Forms

When editing forms whose content is critical to security, it is a good idea to use digital signatures, so that the origin of the form can be verified. This allows you to check whether the source is trustworthy and whether the form or its content has been changed subsequently (integrity).

See also:

Digital Signatures and Certification in Forms

Digital Signatures in Forms

Prerequisites

● ADS Connection

For the signatures, you need a secure connection via SSL or HTTPS. For this, your system needs an RFC connection of type HTTP Connection to External Server for the ADS. The external server for the ADS is the J2EE Engine. See Adobe Document Services Configuration Guide

● Documents with Signature Field

To set and check the signature, the form must have a signature field. You can run insert this in Form Builder (transaction SFP) in Layout.

It does not make any difference whether the signature is server-side or client-side.

Signing a Form

...

1. Create a form with a signature field.

2. To digitally sign your form, click on the signature field.

3. Confirm the subsequent prompts.
The signature information is inserted in the signature field. Example:

Checking the Signature

The validity of the signature is checked Send button that is inserted on the form. This button is then used to send the signed form back to the back end.

Method GET_SIGNATURES of interface IF_FP_PDF_OBJECT is used for this.

For more information, see Scenarios for Setting and Checking Multiple Signatures.

Supported Elements of the Adobe Library Web Dynpro ABAP Integrating Forms

Special UI elements in the Adobe Designer are available for form development in a Web Dynpro ABAP application. Go to the Layout tab page in the form builder. Depending on how the forms are integrated the following libraries are available for Web Dynpro ABAP in the Library group box.

ZCI Forms

If you have selected the entry ZCI Layout as the Layout Type in the form builder's Properties, as a developer of forms based on ZCI you can use the Web Dynpro Native library.

The following elements are currently supported by the Web Dynpro ABAP environment:

Send

With the Web Dynpro form UI element Send, the input data of a PDF form is sent to an SAP backend system. The Web Dynpro context bound to the InteractiveForm (property dataSource in the view designer) is updated with the input data. The event onSubmit of the Web Dynpro UI element InteractiveForm is also triggered.

EnumeratedDropDownList and EnumeratedDropDownListNoSelect

Both value helps can be retrieved from the Web Dynpro library in the Adobe Designer using drag and drop on the form. The difference between the two values is that EnumeratedDropDownListNoSelect does not automatically select a value if either no entry at all is found in the data part or no entry is found that is relevant to the current selection list. Whilst EnumeratedDropDownList would automatically retrieve the first entry from the selection list.

Procedure

1. Place the Adobe UI element as usual on the template and bind it to the context in the data view.

2. Change the element value binding.

a. ChooseElement Values.

On the following popup the following entry for Objects appears below the group title Binding:

$record.sap-vhlist.REPLACE_THIS.item[*]

b. Replace REPLACE_THIS with the SOM expression of the data binding.

You can get this value from the Object menu. This is the value that appears after $record in the standard binding. Example Node.DVH3.

Note that you escape each point with \.

Example of a correct value: $record.sap-vhlist.Node\.DVH3.item[*]

The values of the EnumeratedDropDownList are taken from the VALUE_SET of the bound Web Dynpro attribute. If the type of the attribute is DDIC (ABAP Dictionary) and domain fixed values are defined, these are shown. You can also program the VALUE_SET to fill with values at runtime.

Input Help

The Adobe UI element input help makes it possible to call an input help from the form.

Example of input help in an input field:

Note that the coding of the xfo input help must be slightly adjusted. Enter the name of the bound attribute as field name. In the present example this is CARRID.

● Before:

● After:

So the Adobe UI element input help is the connection to the Web Dynpro ABAP input help.

ACF Forms

Developers of forms based on ACF should use the Web Dynpro ActiveXlibrary (see Documentation about PDF-Based Print Forms).

The following element is currently supported by the Web Dynpro ABAP environment:

Send

With the Web Dynpro form UI element Send, the input data of a PDF form is sent to an SAP backend system for storage. The UI element also provides an automatically generated event.

Documentation about forms and the Form Builder is available under Form Design Using the Form Builder. Note that for Web Dynpro ABAP the interface definition and activation mentioned there is not required.

Documentation on the individual UI elements is available in the online help for the form builder under Help ® Adobe LifeCycle Designer Help, section Working with Objects.

Interactive Form Use Web Dynpro ABAP Integrating Forms

There are many reasons for including forms in a Web Dynpro application. Most embedded forms are used for printing and archiving and therefore do not have to be made available in interactive form. However, the Web Dynpro framework still allows you to use embedded PDF forms interactively. Using a PDF as an input template for a Web Dynpro application can be especially useful when a user is familiar with the appearance of a form and, for reasons of recognition, you would like to also make this form available in the system. An example of this is a tax return form. A further use case for interactive forms relates to legal considerations. It may be necessary to store not only the data content of a form, but retain the form and the data together as a unit for future reference.

Releasing the Interactivity of a Form

In the default system settings, a UI element of type InteractiveForm is non-interactive – that is, the checkbox of the enabled property is not checked. If you wish to use a form interactively, you have to select the property enabled.

Note that you only need to select this checkbox for ACF forms if you want your application to be used interactively. Selecting the checkbox means that the Active Components Framework (ACF) is used for rendering in the client (generally the browser of the user) and must therefore be installed. The ACF is installed centrally from SAP NetWeaver AS, normally automatically when a relevant application is first called. However, it is possible that a user may not have sufficient authorization for the local installation of the ACF-CAB files. In this case, the user cannot display the form. If a form is used without the enabled checkbox being selected – that is, non-interactively – the ACF is not required for rendering.

Forms with ABAP Dictionary-Based Interface Web Dynpro ABAP Integrating Forms

Before the introduction of the XML-based interface, an ABAP Dictionary-based interface was created for a form during integration of the same. Such an interface, however, was not easily linked to the context of a Web Dynpro component. All the forms created from within the Web Dynpro context are not automatically equipped with an XML-based interface. In certain situations, however, it can be necessary to integrate an old form with a function module-based interface into a Web Dynpro application. The Web Dynpro runtime makes it possible, in principle, to display or print such a form within a Web Dynpro application. In special cases, it is even possible to integrate a form of this type in an interactive mode.

Note that forms with a function module-based interface can only be used as PDF-based print forms.

Setting Up Limited Input Enablement

The UI element InteractiveForm can also be used here with limited input enablement. The values entered by the user are not, however, distributed to the respective attributes. The form is displayed in change mode and, after the user has completed his or her entries, it is stored as a whole in the context attribute – which is then mapped to the property pdfSource. This is particularly helpful whenever you want to print or archive entries in a form. Validation of the entries, in this case, is not provided by the framework.

Once a form is set to input enabled, this property is retained. It cannot be reset to a pure display mode again.

The interface of the UI element InteractiveFormcontains the method SET_LEGACY_EDITING_ENABLED, which in turn contains a Boolean parameter. The form is then ready for input when

● The parameter has the value X.

● The property enabled in the UI element InteractiveForm is selected.

● The property pdfSource is mapped to a context attribute of the type XSTRING.

● The property dataSource is mapped to a context attribute that is compatible with the form context.

The form context is used to exchange data between InteractiveForm and the Web Dynpro context. If the form is based on an ABAP Dictionary-based interface, data from the interface is passed to the form context. You have the option of change the attribute names here. You cannot do this in the scenario presented here; you must use the attribute names specified.

The following code fragment shows how to configure the form for input:

method WDDOMODIFYVIEW .

data: LR_INTERACTIVE_FORM type ref to CL_WD_INTERACTIVE_FORM,

LR_METHOD_HANDLER type ref to IF_WD_IACTIVE_FORM_METHOD_HNDL.

check first_time = abap_true.

LR_INTERACTIVE_FORM ?= VIEW->GET_ELEMENT( 'INTERACTIVE_FORM_1' ).

LR_METHOD_HANDLER ?= LR_INTERACTIVE_FORM->_METHOD_HANDLER.

LR_METHOD_HANDLER->SET_LEGACY_EDITING_ENABLED( abap_true ).

.

.

.

endmethod.

Hiding the Adobe Toolbar Web Dynpro ABAP Integrating Forms

You can make a setting to hide the Adobe Reader toolbar. In the default setting this toolbar is displayed.

Example Showing the Toolbar

You can hide the toolbar using method SET_HIDE_TOOLBARS of the UI element interface InteractiveForm IF_WD_IACTIVE_FORM_METHOD_HNDL:

… lr_method_handler->set_hide_toolbars( abap_true ):

Example with Toolbar Hidden

Users can also hide (or show) the toolbar by choosing the function key F8 within the application.

File Export Web Dynpro ABAP Integrating Forms

Use

You can export files in accordance with the FileDownload functionality, thereby fulfilling the usual security requirements. This download functionality is available in every action handler, for example, when clicking a Button, a LinkToAction or (what you should not do) when switching a TabStrip or clicking a RadioButton.

When the user clicks the respective UI element, a binary data stream is generated. For this data stream, the appropriate URL is generated and the result is displayed in a separate browser window.

Features

For both cases, whether to export a single file or several files, the same ways of displaying and storing the file(s) exist:

· Display in the same window

Example:

· Save query in the same window

Example:

· Display in a separate window

· Save query in a separate window

With the MS Internet Explorer, the Save query for several files does work only with the external window. Therefore, simultaneously downloading several files is always done via external windows.

Activities

Use the method ATTACH_FILE_TO_RESPONSE of class CL_WD_RUNTIME_SERVICES for the file export.

Example

For an example for the file export via a button, see the component WDR_TEST_EVENTS in the view Button. The area to the right contains the test example for all eight cases in the bottom group.

Dynamic Programming Programming Web Dynpro ABAP

Web Dynpro offers the frame for you to lay out the user interface structures of your business application as declarative as possible. Nevertheless, with increasing complexity of the application, it may become necessary to make certain decisions only at runtime.

The dynamic embedding of an interface view into a window in the context of a dynamically created component usage is an example for dynamic programming within a Web Dynpro application. In addition, you may influence, for example, the structure of a context at runtime; you may add elements to a context at runtime.

Besides, you can change the layout of a view at runtime, which means that you can dynamically add UI elements.

Dynamic Layout Manipulation Dynamic Programming Programming Web Dynpro ABAP

Under certain conditions, it may be useful to change the layout of a view at runtime. In this context, you can add as well as remove UI elements. You can also change the dynamic properties of a UI element, bind an event to an action or manipulate the Parameter Mapping of Event Parameters.

Basically, you should use the dynamic manipulation of the layout – just like the dynamic manipulation of the context – only if it is not possible to construct a component by declarative means. This may be the case if parts of the component are not yet knows at design time.

To make changes to the structure of a view layout, you must use the method WDDOMODIFYVIEW (or a method called within it).

For a complete list of all UI element classes and their methods, refer to the reference part of this documentation.

Containers and UI Elements

To use the dynamic layout manipulation correctly, you must understand the structure of a view: In a view, a number of UI elements is laid out in relation to one another. This is done in so-called containers. To describe it, a layout is selected for every container: FlowLayout, MatrixLayout, or RowLayout exist (see reference documentation, chapter Layout). Every UI element has layout data, in accordance with the embedding container. This layout data contains the description, at which position in the layout of the container an embedded UI element has its place.

The layout of the container and the layout data of the embedded UI element must always match. Example: If the container is of type FlowLayout, then the layout data of the embedded UI elements must be of type FlowData.

When a view is created, it already contains an empty container, the ROOTUIELEMENTCONTAINER. Within this container, the entire view layout is structured.

Adding a UI Element to a Container

To add a new UI element to a UI element container, proceed as follows:

● You must determine what kind of a UI element it is.

● For the container element to which to add the new UI element you must create a reference (method view->GET_ELEMENT).

● You must determine the position in the container layout, where to fit in the new element. For this purpose, you must create the layout data for the newly created UI element.

The code fragment below shows the steps required to add a UI element of type Button:

method WDDOMODIFYVIEW . data: LR_CONTAINER type ref to CL_WD_UIELEMENT_CONTAINER, LR_BUTTON type ref to CL_WD_BUTTON, LR_FLOW_DATA type ref to CL_WD_FLOW_DATA. LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( ). LR_FLOW_DATA = CL_WD_FLOW_DATA=>NEW_FLOW_DATA( element = LR_BUTTON ). LR_CONTAINER ?= view->GET_ELEMENT( 'ROOTUIELEMENTCONTAINER' ). LR_CONTAINER->ADD_CHILD( LR_BUTTON ). . . endmethod.

Properties of the Newly Added UI Element

If you want to set a property of the UI element during the dynamic creation, pass the values when you create the element. To enhance the above example with a text on the button to be created (the text has been created before in the Online Text Repository):

data: MY_TEXT type string. MY_TEXT = CL_WD_UTILITIES=>GET_OTR_TEXT_BY_ALIAS( 'MY_TEXT_ALIAS' ). LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( text = MY_TEXT ).

A property like the text of the button can also be used later. For this purpose, the class CL_WD_BUTTON, and all other basis classes of UI elements, contains the appropriate method – for the example above, this is the method SET_TEXT. In the same manner, you can set or change all other properties of a UI element. For example, you can assign an action (which you created independently) to the button or change the assignment dynamically.

LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( text = MY_TEXT On_action = MY_ACTION ).

Besides, you can bind properties of UI elements to context nodes. To do this, the class CL_WD_[UI element type] contains a set of methods BIND_[property type]:

Working Dynamically with Parameter Mappings Dynamic Programming Programming Web Dynpro ABAP

The term parameter mapping is used for the bind of an event parameter to a parameter of an action handler method.

Background

A number of UI elements is able to trigger events. Each of these events has predefined parameters; for example, every event has the parameter ID. Depending on the type of the related UI element, other parameters may additionally be predefined. However, these event parameters are not represented individually in the development environment; for a complete list of all events and their related parameters for every UI element, see the reference part of this documentation.

In the handler method of the action related to the event, you can now use this event parameter by creating a parameter with the same name for the method. The mapping between these two parameters always occurs via similarity of names (see also Parameter Mapping in the fundamental part of this documentation).

Example: Every event has a parameter ID, to which the name of the respective UI element is assigned as value. If you create a parameter named ID in the handler method of the related action, the value of the event parameter with the same name is automatically passed to it.

Dynamically Creating Additional Event Parameters

You can create and use other parameters besides the event parameters predefined by the meta model. However, this procedure is applicable only within the frame of dynamic programming.

Adding additional event parameters must always be implemented in the method WDOMODIFYVIEW.

Example

A view contains several UI elements of type LinkToAction. The link the user activates controls the subsequent display within the view. Depending on the selected link, an attribute (for example, with the name ”CLICKED_AT”) of the view context must receive a specific value. The handler method of the only action (for example, with the name ”ON_CLICK”) of this view copies this value from the respective event parameter, which has been created for each of these UI elements and has been added dynamically to the respective event.

For this procedure, you must perform the following three steps:

· Create the additional parameter

· Set its value which depends on the UI element

· Assign the parameter to the respective event.

The coding below shows these three steps for the example above:

METHOD wddomodifyview. DATA: lt_parameters LIKE if_wd_event=>parameters, parameter LIKE LINE OF lt_parameters, lr_link1 TYPE REF TO cl_wd_link_to_action, lr_link2 TYPE REF TO cl_wd_link_to_action. .

First, for method WDOMODIFYVIEW two variables are declared: one for the event parameters to be newly created and one for the local table that administers them. In addition, you need a variable of corresponding type for each of the UI elements.

. . CHECK first_time = abap_true. lr_link1 ?= view->get_element( 'LINK1' ). lr_link2 ?= view->get_element( 'LINK2' ). . .

The parameter view is automatically known in each method WDOMODIFYVIEW. The two local variables are assigned by means of the related interface IF_WD_VIEW and the ID (Link1/Link2) of the respective UI element.

. . parameter-name = 'MYID'. parameter-value = 1. parameter-type = 'g'. INSERT parameter INTO TABLE lt_parameters. lr_link1->map_on_action( lt_parameters ). . .

Then the new parameter receives a name, value and type and is added to the local table. If you want to add several parameters to the event of this UI element, repeat the last three steps as often as required and also add the additional parameters to the local table.

Use the command lr_link1->map_on_action( lt_parameters ) to link the local table to the event.

. . CLEAR lt_parameters[]. parameter-name = 'MYID'. parameter-value = 2. parameter-type = 'g'. INSERT parameter INTO TABLE lt_parameters. lr_link2->map_on_action( lt_parameters ). ENDMETHOD.

After resetting the local table, the steps are repeated for the second and all other events.

As the result of this procedure, the events of the two UI elements Link1 and Link2 each contains a parameter named MYID, however with different values. When the respective event is triggered, the runtime automatically passes the new parameter to the action handler method, by which it is evaluated appropriately.

A simple variant of the action handler method ONACTIONON_CLICK could look like this:

Parameter Declaration type Reference type WDEVENT Importing CL_WD_CUSTOM_EVENT MYID Importing STRING

METHOD onactionon_click. wd_context->set_attribute( name = 'CLICKED_AT' value = myid ). ENDMETHOD.

The value of the event parameter MYID is passed to the context attribute CLICKED_AT and can now be used for further control.