Skip to Content

Different Types of Context Nodes

Value Nodes:

A Value Node is the most basic form of node that can exist within a Webdynpro Context. It is one in which all the necessary metadata to define the node attributes either is stored within the node itself or is obtained from a local Java Dictionary object. Value node attributes can be added manually as required and do not necessarily have to represent a predefined data structure.
However, if you know that a certain combination of fields will be used frequently across the different contexts in your application, then rather than repeating the structure declaration for each value node in each context, it is more efficient to create a dictionary structure. Then, when you create a value node, you can obtain the attributes directly from the dictionary structure using structure binding. Under these conditions, the attributes of the value node become fixed, and can only be taken from the dictionary structure.
A value Node that uses structure binding may not have any further child attributes added to it, but you may add further child nodes (which in turn may use structure binding if desired).
When creating a new element for a value node’s element collection, the node can create the element object using the metadata stored within it. In a generalized form, the coding looks like this (where {cn} is any context node):

I{cn}Element newValueElement = wdContext.node{cn}.create{cn}Element();

Model Nodes:

A Model node is similar to a value node in respect to it’s API however there are three important differences:

  1. A Context model node makes a model object look like any other context node i.e. it gives the model object an API that is very similar to a value node.
  2. A Model Node is not considered valid until it is bounded to a corresponding model object; therefore a model node always inherits its metadata from the model object to which it is bound.
  3. The element collection in a model node does not hold the actual runtime data instead it holds a collection of references to the relevant model object instances.

When creating the elements of a model node’s element collection you cannot use the exact syntax shown above for a value node. Instead, the instance of a relevant model objects. A reference to this instance is then added to the model; node’s element collection.
The actual runtime data is stored in the model objects, not in the model node’s element collection. For Instance, a new element can be added to the model node BAPI_FLIGHT_GETLIST_INPUT as follows:

Notice that the create{mn}Element() method of a model node cannot create a new element object on it’s own; it needs to be passed a reference to an existing model object. The Model object is the actual repository for the runtime data and the references to these model objects are maintained in the model node’s element collection.

Recursive Nodes:

If you wish to represent a recursive data structure within the context, a recursive node is the correct node to use. The simplest example of recursive data within a hierarchical structure is a file system. A dictionary can contain either files or subdirectories. This definition is then repeated for each subdirectory level down the hierarchy.
Within the context, a recursive node is a special node that has only two properties: name and repeatedNode. As with any context node, a recursive node must itself name, but the repeatedNode property is where the recursion is defined. This property holds a reference to some parent node and indicates that, at runtime, the location of the recursive node will be occupied by a node of the type indicated in the repeatedNode property.
You should think of a recursive node as a design time placeholder used to indicate a node will be created at this location at runtime, and will be of the type named in the repeatedNode property.
The node name identified by repeatedNode must lie on the direct path back to the context root node. When a recursive node is created at runtime it always created as a non-singleton node. This is a hard-coded feature and cannot be changed.
The Following code will use the recursive context structure shown below, to create a representation of the simple directory and file structure shown below.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.