There are a few interesting aspects regarding the context and view elements. These are either some nice but largely unknown features or pitfalls almost everyone stumbles across while writing his or her first Web Dynpro application. ![image]()
Binding Into Empty Sub Nodes
This pitfall happens quite often in master/detail scenarios where the detail data is displayed as a form and data is loaded by a generic algorithm – in most cases directly from the database.
If the master entry has no detail data, the context node representing the detail data will be empty. Hence, the form‘s ui elements will not have a place to get their data from or be able store them. This leads to a short dump.
The solution is to either provide an empty context element or to make the detail area invisible.
Web Dynpro ABAP offers a helper method in class CL_WD_DYNAMIC_TOOL called SET_VISIBLE_FROM_ELEMENT to offer some basic support. Just supply the path to a context element. If the context element does not exist, the ui element supplied in ALTERNATIVE_UIELEMENT_ID will be made visible and the one supplied in UI_ELEMENT_ID will be made invisible.
DDIC Binding
This useful feature allows a developer to bind an attribute of a view element to a property of a data element in the data dictionary. The following DDIC properties are supported:
- Visible length
- Some to be displayed text
- Short description
- Medium description
- Long description
- Most fitting text
- Short text (the text below the type name in se11)
There are two different types of DDIC binding – explicit and implicit one.
Explicit DDIC binding directly binds an attribute of a view element to a property of a data element or to the data element of a context attribute. So a developer specifies at design time or runtime that a certain property of a view element should get its value from the DDIC. There is web log that describes how DDIC binding can be specified at runtime. It can be found Dynamic Programming in Web Dynpro ABAP - Part III: Aggregations and DDIC-Binding of ViewElements.
Implicit DDIC binding uses the binding of the primary property of the current view element or that of a referred view element. Implicit DDIC binding always happens automatically if no text was specified for certain properties of certain ui elements and cannot be influenced by an application developer.
An example for implicit DDIC binding is a Label that refers to an InputField. Suppose the value attribute of the InputField binds to a context attribute of type S_CARR_ID. Now the runtime automatically displays the text of the S_CARR_ID. The runtime retrieves the text of the caption of a header of the table column in a similar way.
Binding Attribute “visible” to a Boolean
As nice as this feature is as unknown it is to many developers. I have seen applications where a boolean supplied by the business logic gets converted into a value of the visibility enum although this is not necessary. Just type your context attribute as WDY_BOOLEAN (the Web Dynpro ABAP standard boolean attribute) and bind your visible attribute to it. The runtime automatically maps false to none and true to visible.
Expressions in Binding Paths
This is best explained by providing an example: Suppose you have two areas, but only one of them should be visible. Using the hint mentioned above you would bind the visible attribute of the two areas to two wdy_boolean typed attributes in the context and supply opposite values in each of them. Well, this is not necessary. A single boolean attribute is enough to handle this case.
Simply bind the visible attribute of the first ui element to the boolean attribute as usual and select the “NOT” checkbox at the binding popup while binding the second visible attribute to the same context attribute. Now, whenever the first area is visible, the other one will be invisible and vice versa. The benefit: Only a single context attribute needs to be filled.
Of course, while performing dynamic programming, it is also possible to specify such an expression. Just add “:NOT” at the end of the binding path, e.g. „MY_PATH.MY_NODE.MY_ATTRIBUTE:NOT“.
In addition to NOT, there is also another expression called FINAL. It is mainly used in configuration and personalization to determine if the value of a particular context attribute can be changed further. Please excuse me for not going too much into detail here, but we would get sidetracked heavily as configuration and personalization is a huge topic by itself. Despite of this, the value can be addressed adding ":FINAL" at the end of a binding path.
It is possible to combine multiple expression, like ":NOT:FINAL".
Binding to Structured Attributes
Suppose you have the following situation: The fields displayed in a table are fields of a DDIC structure. The table binds to a context node that uses this structure. The problem is now that if the table is going to be editable, additional attributes of the cell editors need to be bound:
- enabled
- readOnly
- state (for setting a field to required)
- visible (for hiding values per row level due to authorization checks)
There are a few possible options how to solve this problem of representing the actual data along with those additional attributes.
Solution 1:
Create a 1:1 sub node per data attribute containing the missing attributes. Each of these sub nodes uses the same DDIC structure.
Solution 2:
Variation of solution 1: Create a new DDIC structure that contains the original field and adds the four additional fields as well. Add as many 1:1 sub nodes to the original node. Have no attributes at the main nodes.
Solution 3:
No sub nodes at all. All additional attributes are added to the data node. Some naming convention is applied.
What are the benefits and the drawbacks of these solutions?
First off, having more context nodes means more generated source code, longer activation time of a component, higher ABAP load and the chance that the generated class that represents a component might not fit into memory anymore. Additionally, the performance of the renderer will be worse since it needs to parse the longer path. What’s even worse is that the renderer won’t be able to reuse the context element that was accessed previously as the data of each column is stored inside of a different context node.
Secondly, more attributes at the same level means bad maintainability. The overwhelming number of attributes makes it difficult for the customer or industry to enhance an existing application. There are applications with several hundred attributes per node. This is bad design.
A better solution would be instead of creating sub nodes to create an additional context attribute per data attribute and type it by the DDIC structure mentioned in solution 1. There won’t be additional sub nodes and the number of attributes per node will still be mangeable. Unfortunately, binding into structured attributes is currently only possible at runtime. Such attributes can be addressed using “–“ (the common notation in ABAP). An example would be. “MY_NODE.MY_ATTRIBUTE-MY_STRUCUTED_ATTRIBUTE”.
Binding Paths with Denoted Context Elements
If you bind an attribute of a view element at design time using the point-and-click UI, the binding path will always follow the leadSelection. An example is “NODE.SUB_NODE.SUB_SUB_NODE.ATTRIBUTE”
At runtime there is no such restriction. A binding path can denote specific context elements. An example is “NODE.SUB_NODE.7.SUB_SUB_NODE.ATTRIBUTE”.
This can be useful when you want to display something for which you can‘t change the leadSelection (since it is used for something else) or if no leadSelection exists (e.g. displaying the detail data of two rows of a table for comparing them).
Even if this is a runtime-only feature, you might still want to keep the design time support. This is possible by binding the attribute using the design time tools and adjusting the binding path slightly afterwards i.e. in wdDoInit.