Conditions and Naming Conventions for Import Beans 

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 Get methods. There is also the prerequisite that the relations between the Java classes have been implemented using Get methods. 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, andjava.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 required; a Get/Set method is sufficient.

Example

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..* or1..* 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 Set method, respectively. For example, the property name firstName is identified for the Get method public 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 table below provides a summary of the naming conditions:

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 property X of 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 property X of 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 way of preventing properties from being changed is to mark a property in the model declaration as read-only and not to provide a 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 parameters and return types of the relation access.

Get Methods

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

Cardinality of relation	Method	Description
x:1	ModelClass getX()	Returns the relevant object of 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 relation role X between C1 and C2.

Collection mutator methods are not supported.