Naming Conventions for Coding Entities 

Applications:  {n_a} = {a}App

The application name {n_a} is defined by the desired name {a}, followed by the suffix App. {a} describes the business process to be delivered.

Components:  {n_c} = {c}Comp

The component name {n_c} is defined by the desired name {c}followed by the suffix Comp. {c} describes a (reusable) unit of functionality within the application.

Component Interface Views:  {n_civ} = {w}InterfaceView

The creation of window {w} automatically causes a component interface view {n_civ} to be created where {n_civ} = {w}InterfaceView. You may not change this name.

The interface view presents the view assembly defined in {w} to the client layer.

Component Usage:  {n_u} = {n_c}{p}Inst

In order for component A to use the data and functionality within component B, component A must first declare the use of component B.

The name of the component usage differs from the name of the component in the same way that the name of an object instance differs from the class it instantiates.

The usage instance name {n_u} is defined by the previously defined component name {n_c}, followed by the usage purpose {p} and the suffix Inst.

Custom Controllers: {n_cc} = {cc}Cust

The custom controller name {n_cc} is defined by the desired name {cc}followed by the suffix Cust.

Inbound Plugs:  {n_pi} = {pi}In

The actual inbound plug name {n_pi} is defined by the desired name {pi}followed by the suffix In.  {pi} should start with an upper case letter.

The first letter of the plug name should be uppercase. To distinguish between inbound and outbound plugs, use the ending In for inbound plugs and out for outbound plugs.

Inbound plugs are used to link outbound plugs with navigation targets. In contrast to outbound plugs, every inbound plugs comes with a corresponding inbound plug event handler onPlug<Inbound plug name> in the view controller. The function of the target view should be part of the name of the inbound plug.

All inbound plugs have a corresponding event handler in the view controller. This method has the name onPlug{n_pi}.

Models:  {n_m} = {m}Model

The model name {n_m} is defined by the desired name {m} followed by the suffix Model.

SAP strongly recommends that each Web Dynpro model belongs to its own Java package.  Failure to adhere to this recommendation could result in incorrect behavior of objects within the model, especially if they are used by multiple Web Dynpro components.

Outbound Plugs:  {n_po} = {po}Out

The outbound plug name {n_po} is defined by the desired name {po}followed by the suffix Out.  {po} should start with an uppercase letter.

The first letter of the plug name should be uppercase. To distinguish between inbound and outbound plugs, use the ending In for inbound plugs and out for outbound plugs.

Outbound plugs are fired when you navigate to other views from one or more navigation links attached to the outbound plug. Because the set of navigation links attached to an outbound plug (targets) may vary due to redesign or customization, you should not include the function of the navigation target in the name of the outbound plug. This name should indicate the reason for firing the outbound plug.

Examples:

A view for entering form data has an outbound plug which is fired to navigate to a result view. Instead of naming it ShowResultOut (navigation target), it is better to name it SearchDataEnteredOut.

Projects:  {n_p}

The project name {n_p} defines the category of the business processes being delivered.

Standalone Component Interfaces:     {n_si} = {si}CompI

The standalone component interface name {n_si} is defined by the desired name {si}followed by the suffix CompI.

Standalone Component Interface Views:   {n_siv} = {n_si}{siv}

If only one interface view is needed for a component interface, no manual action is needed because the SAP NetWeaver Developer Studio automatically adds the suffix InterfaceView  to the window name {w}.

If multiple interface views are required, subsequent standalone component interface view names should be defined by the standalone interface name {n_si} followed by a distinguishing name {siv}.

Views:        {n_v} = {v}View

The view name {n_v} is defined by the desired name {v} followed by the suffix View.

Viewsets:    {n_vs} = {vs}Viewset

The viewset name {n_vs} is defined by the desired viewset name {vs} followed by the suffix Viewset.  The value of {vs} is typically the same as the name of the window {w} in which it is contained.

SAP does not currently have a recommendation for naming nested viewsets.

Windows:   {n_w} = {w}

A window {w}represents an arrangement of one of more views that form the visual interface for controller {n_ctl}.  The composite name for such an arrangement of views is a view assembly.

A window and a component interface view should be considered as two aspects of the same view assembly.  The component interface view provides programmatic access to the view assembly, whereas the window is used to deliver a view assembly to the client.

Since window {w} does not relate to a specific piece of Java coding, it is not necessary to use a particular suffix in its name.

Naming conventions for context entities

Should Node Names be Singular or Plural?

The name chosen for a given context node {cn} should reflect the potential number of elements the node collection will contain at runtime. Therefore the node’s cardinality determines whether the name will be singular or plural.

If a node has a cardinality of 0..1 or 1..1, there will be at most one element in that node collection.  Therefore the node name should be singular.

If, however, the node has a cardinality of 0..n or 1..n, the node collection could contain multiple elements.  Therefore, the node name should be plural.

General Naming Standards

When choosing a name for a context node or attribute, it is not normally necessary to include the words “node”, “element” or “attribute” as a means of identifying that this entity belongs to the context.

The exception to this rule is when the name of the business data being stored by the context contains the word “node”, “element” or “attribute”.

The Web-Dynpro-Framework generates various classes that add these words to the given name {cn}.

Classes Generated as a Result of Design Time Declarations

The creation of node {cn} within controller {n_ctl} causes the classes IPublic{n_ctl}.I{cn}Node and IPublic{n_ctl}.I{cn}Element to be generated.

The methods implemented by these classes vary depending on whether a child node {chn} exists for the parent node {cn}, and, if {chn}does exist, whether or not it is a singleton.

In Table 1 below, methods that have a grey background  only exist if node {cn} has a child node {chn}.

Generated Class	Method
Context Node
IPublic{nctl}.I{cn}Node	I{cn}Element create{cn}Element()
	I{cn}Element current{cn}Element()
	I{cn}Element get{cn}ElementAt(int)
	void bind(I{cn}Element)
	I{chn}Node node{chn}()
	I{chn}Node node{chn}(int)
Context Element
IPublic{nctl}.I{cn}Element	String get{cn}Name()
	void set{cn}Name(String)
	I{chn}Element current{chn}Element()
	I{chn}Element create{chn}Element()
	I{chn}Element get{chn}ElementAt(int)
	I{chn}Node node{chn}() This method  only exists if the child node {chn} is a non-singleton with respect to its parent node {cn}.

Table 1: Generated Context Classes

All node names declared at design time must be unique within the entire context.

Model nodes:  {mn}

A model node name {mn} should start with an uppercase letter.  To make the generated code easier to read, {mn} should have the same name as the class within the model to which it will be mapped.  This is not mandatory, but makes easier to read the generated code.

A model should always belong to its own Java package.

All node names created at design time must be unique within the entire context.

Recursive nodes: {rn}

A recursive node name {rn} should start with an uppercase letter. You can select any meaningful name that adheres to the Web Dynpro naming convention for context names.

All node names created at design time must be unique within the entire context. This rule may only be broken if a recursive context node is added dynamically. This is the only case where you may have duplicate node names within the context.

Supply functions:     supply{cn}()

By default, the SAP NetWeaver Developer Studio creates a supply function for a context node in the form supply{cn}. You may alter this name if required, but for the sake of simplicity and consistency, SAP recommends that the default name be used.

If a node’s supply function is called during screen rendering, it must not throw any exceptions, because this would result in the WDF terminating your application.

Value nodes:  {vn}

A value node name {vn} should start with an uppercase letter.  You are free to select any meaningful name that obeys the Web Dynpro naming convention for context names.

All node names created at design time must be unique within the entire context.

Value Attributes: {va}

A value attribute name {va} should start with an uppercase letter.  You may select any meaningful name that adheres to the Web Dynpro naming convention for context names.

All attribute names must be unique within the scope of their parent node.

Calculated Value Attributes:  {cva}Calc

A calculated value attribute name {cva} should start with an uppercase letter and end with the suffix Calc. You may select any meaningful name that adheres to the Web Dynpro naming convention for context names.

All calculated attribute names must be unique within the scope of their parent node.