Start of Content Area

Background documentation Conditions and Naming Conventions for an Import Bean  Locate the document in its SAP Library structure

Conditions

There are API-relevant aspects involved in the JavaBean model binding. The JavaBean classes must be fully qualified and the properties must be implemented using Set and/or Getmethods. In addition, there is the prerequisite that the relations between the Java classes have been implemented using Getmethods. For all Web Dynpro-relevant properties, methods, and relations of the bean, there is the rule that these must be modeled using public visibility.

The data types for the properties are limited to primitive types and wrapper classes. Exceptions are byte and java.lang.Byte. In addition, java.lang.Object, java.math.BigDecimal, java.sql.Date, and java.sql.Time are supported. java.util.Date is not supported; instead, use java.sql.Date. The other complex data types are identified as relations.

For each property, there must be a Get method available for read-only properties as well as a Set method for read/write properties. A corresponding member is not necessary; a Get/Set method suffices.

ExampleExample:

For the read/write property String firstName, the two following methods must be implemented:

 

public String getFirstName();

public void setFirstName(String value);

 

The Get methods that return non-primitive types are recognized as relations. Depending on the cardinality of the relation roll, the accessors/mutators are as follows:

 

Single relation roles (cardinality 0..1 or 1..1)

 

public Customer getCustomer();

public void setCustomer(Customer value);

 

Multiple relation roles (cardinality 0..* or 1..*)

 

public java.util.List getOrders();

 

In this case, it is sufficient if relations with cardinality 0..* or 1..* return a java.util.Collection-compatible type.

 

Naming Conventions

Properties

The name of the imported model property becomes the technical name of the corresponding Get or Setmethod, respectively. For example, the property name  firstName is identified for the Getmethodpublic String getFirstName().

Relations

The following rules apply for the relations:

 

Relation<className>.<propertyName>

<className> is the name of the JavaBean class for which this relation is identified. <propertyName> is the technical name of the Get method whose return type is not a simple type.

 

Source role name

In the case of a unidirectional relation, the name is <relationName>.<untitled>; for a bidirectional relation it is <className>. Here the name stands for the name of the JavaBean class for which this relation is identified.

 

Target role name

<propertyName> is the technical name of the Get method whose return type is not a simple type.

 

The following table provides a summary of the naming conditions:

This graphic is explained in the accompanying text

A:   Aggregation
C:   Cardinality
N:   Navigation options

If there is a relation between the target and the source class, navigation is possible. Otherwise, it is set to false.

 

Specification for Model Properties and Relations

Access to Properties

For each property that is to be bound to a Web Dynpro context, the JavaBean model must provide appropriate access methods that comply with the bean conventions.

Get Methods

ScalarType getX()

Gets the property X of the type ScalarType

Note that these Get methods must supply only scalar types, in accordance with the relations accessors.

Mutator Methods

Void setX(ScalarType value)

Sets the property X of the type ScalarType to value

Mutator methods – or Set methods, in this case – are only needed for those properties that the client can change later on. Another option for preventing changes to properties is to mark a property in the model declaration as read-only and not to provide any mutator method. It is also possible to declare a context as read-only if a model property is changeable.

Access to Relations

ModelClass represents the placeholder for the parameters and return types of the relation access.

Get Methods

The following table assumes there is a relation between the model class C1 and the model class C2 with the role name X.

Cardinality of the relation

Method

Description

x:1

ModelClass getX()

Returns the relevant object of the type ModelClass, according to the relation role X between C1 and C2. If no such object exists, the behavior of the method is not defined.

x:1..n

Collection getX()

Returns the relevant non-empty object collection of the type ModelClass, according to the relation role X between C1 and C2.

Collection mutator methods are not supported.

 

End of Content Area