The 'Composition Application - Missing Manuals' initiative hosted on the SDN Code Exchange Platform aims to create a productivity starter kit and sandbox system for the development of Composites by providing technical libraries and an easy demo app documenting its features & how-to use them.
Links: Composition Application - Missing Manuals | Twitter
Extensibility is a design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend an application and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions.
The main benefits are:
Loose- Coupling
Without modifying the original code
Development efficiency
Extensibility can also mean that a software system's behavior is modifiable at runtime, without recompiling or changing the original source code.
Let's see how we can achieve this in webdynpro for java:
Create a separate webdynpro component interface which exposes the interface view / method which can be implemented by customer for extension
Declare the usage of the interface in the consuming component at design time
Keep the lifecycle to manual. Consuming component will create the component usage itself at runtime
Add a view container UI element in the consuming view, and in the consuming window declare the usage for the referenced component interface
Now, in wdDoInit() method of consuming component, create the component dynamically based on the DC name & the component name of the custom implementation. Do it using the following code snippet :
IWDComponentUsage componentUsage = wdThis.wdGetCustomerSubScreenComponentUsage();
if (componentUsage.hasActiveComponent())
{
componentUsage.deleteComponent();
}
try
{
componentUsage.createComponent("compName", "dcName");
}
catch (Exception e)
{
// TODO: handle exception
}
DC name & component name can be taken from application properties which can be changed at runtime. Customer can now create an implementation which will implement the interface & this implementation will be invoked at runtime. Different customers can override the default implementation according to their business requirements.
There could be requirement where we do not want to extend the whole screen but simply want to change some functionality (e.g.: some extra validations). To achieve this, a faceless interface/ component can be used. A faceless component is one with no visual interface, which means zero views & zero windows. It is useful when a complex unit of functionality requiring no direct user interaction needs to be encapsulated.
Now, the interface definition would not include any interface views, just the required methods to extend the functionality, which can be implemented by customer, and then we will have to call the method at the appropriate place using the following code snippet in our source code.
if (componentUsage.hasActiveComponent())
{
wdThis.wdGetCustomerSubScreenInterface().displayMessage("Hello World!");
}
With the method which is exposed, we can restrict the data which we want to expose for the customer from the running session for security reasons.
This can also be used to change the application's behavior at runtime. We can provide a default implementation for this interface & in case customer wants to override, he can create his own implementation and change the application property & the new implementation would be executed instead of the default one.
4 Comments
