
Components and Interface Definitions
The Web Dynpro Framework enables you to use functions and data from one component in another by using a component in another component . A prerequisite for this is that a usage declaration is created in the "using" component at design time. This itself requires the used component to exist and be recognized by its name. This is not always the case, however. To help you in cases whether the used component cannot be identified, Web Dynpro Framework offers a less rigid technology: Component interface definitions . In this case, you first enter the usage of a separately defined component interface. All components that implement precisely this interface definition can now be used by means of the usage declaration from the main component. The concrete implementation of this method is passed as a parameter at runtime.
If a component wants to embed two components that are not yet known at design time, all components that are able to be embedded must implement a common interface definition. The calling component creates two usages for the interface. At runtime, the implementation is passed as a parameter when the used components or interfaces are created.
General Information About Handling Interfaces
A component can implement multiple interfaces.
Interfaces cannot be inherited.
You can implement interfaces in the Application Configuration or by calling them as ULR parameters.
Interfaces do not implement their own namespaces. We recommend strongly that you use prefixes when you name your interfaces.
Implementation of Interfaces for Customer Developments
Using interfaces in a Web Dynpro component benefits customers by giving them a clean basis for their own further developments. When creating a local development, you can implement a used interface in a separate component and add your own aspects to an application delivered by SAP.
Usage Groups
In certain circumstances, you may want a main component to use an individual component more than once. To enable this, you can create multiple usages for the same component. The same applies to the usage of interface definitions.
As long as the number of used components is reasonable and known already at design time, we recommend that you use a usage group instead of a static list of individual usages. Usage groups organize the dynamically programmed use of components or interface definitions.
Before you decide to use a solution that involves dynamic component usages, remember that you also need to program navigation to any components whose use is implemented using usage groups. This makes navigation more complicated and also means that the application is more difficult to maintain.