Web Dynpro Java - Archive

SAP® Education

SAP Developer Network Web Dynpro

© 2008 SAP AG The concept of componentization in Web Dynpro Java with an exercise Chris Whealy

Page 1 of 24

Web Dynpro Java

The concept of componentization in Web Dynpro Java with an exercise

NetWeaver 7.1 CE Chris Whealy, NetWeaver EMEA RIG

SAP® Education

SAP Developer Network


Page 2 of 24

Copyrights � No part of this publication may be reproduced or transmitted in any form or for any purpose without the express

permission of SAP AG. The information contained herein may be changed without prior notice.

� Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

� Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

� IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

� ORACLE® is a registered trademark of ORACLE Corporation.

� UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

� Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

� JAVA® is a registered trademark of Sun Microsystems, Inc.

� JavaScript® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

� MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

� SAP, SAP Logo, R/2, R/3, NetWeaver, Web Dynpro and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are trademarks of their re-spective companies.

SAP® Education



Page 3 of 24

Content

1 About the Author..................................................................................5

2 Prerequisites ........................................................................................6

2.1 Reader understanding..................................................................................... 6

2.2 Installed software ............................................................................................ 6

3 About this document ...........................................................................7

3.1 Structure ......................................................................................................... 7

3.2 Graphics and screen shots.............................................................................. 7

3.3 Terminology .................................................................................................... 7

4 Componentization in Web Dynpro Java.............................................8

4.1 The Web Dynpro Component.......................................................................... 8

4.1.1 Component Interfaces................................................................................. 9

4.1.2 Controllers within a component................................................................... 9

4.1.3 Why are there two types of controller?........................................................ 9

4.1.4 Models........................................................................................................ 9

4.2 Dividing Business Functionality into Components ......................................... 10

4.2.1 Component Hierarchies ............................................................................ 10

4.2.2 Component Types .................................................................................... 11

4.2.2.1 Utility Components ............................................................................... 11

4.2.2.2 Model Components .............................................................................. 11

4.2.2.3 Visual Components .............................................................................. 12

4.2.2.4 Faceless Component ........................................................................... 12

4.2.2.5 Intermediate Components .................................................................... 12

4.2.2.6 Root Component .................................................................................. 12

4.3 Component Interface Definitions ................................................................... 13

5 Working with Component Hierarchies .............................................16

SAP® Education



Page 4 of 24

Figures Figure 1: General architecture of a Web Dynpro component............................................................................ 8

Figure 2: Component granularity is balance between two extremes .............................................................. 10

Figure 3: A component’s reusability varies depending on its position in the hierarchy................................... 11

Figure 4: The direct declaration of child components introduces a tightly coupled relationship between the parent and the children............................................................................................................................. 13

Figure 5: The direct declaration of child components introduces a tightly coupled relationship between the parent and the children............................................................................................................................. 14

Figure 6: At runtime, a suitable component can be instantiated in order to provide the implementation described by the component interface ..................................................................................................... 15

Figure 7: The IPerson interface and the three components ............................................................................ 17

Figure 8: The overall relationship between the components and component interface.................................. 18

Figure 9: The IPerson interface view embedded into the root component view ............................................. 20

Figure 10: The images are located in the Resources branch.......................................................................... 21

Figure 11: The first screen of the demo application ........................................................................................ 23

Figure 12: The two child components are now accessible through the common interface............................. 23

SAP® Education



Page 5 of 24

1 About the Author

Chris Whealy started working with SAP software in 1993 making assembler modifi-cations to the RF and RV modules of R/2. He then went on to work as a Basis con-sultant installing and upgrading R/3 systems, starting with R/3 version 2.0B.

In May 1995, he joined SAP (UK) as a Basis Consultant and ABAP programmer; however, when the first Internet boom started in 1996, he turned his attention to Web-based interfaces into SAP. This led to him working with the earliest versions of the Internet Transaction Server (ITS), and consequently, he taught the first course on this subject in January 1997. Since then, Web-based front ends for SAP func-tionality have been the main focus of Chris’ attention.

In January 2003, he started working with Web Dynpro and has worked closely with the development team in Walldorf, both learning the product and writing proof-of-concept applications. The knowledge gained whilst working with the developers became the foundation for the book “Inside Web Dynpro for Java” published by

SAP PRESS in November 2004. This book is now in its second edition (September 2007).

Chris is also the author of the standard SAP training courses for Web Dynpro Java: JA310 “Introduction to Web Dynpro Java”, JA312 “Advanced Web Dynpro for Java” and the E-Learning course JA314 “The Internet Graphics Server”

Chris lives in the UK, and works as the Web Dynpro Java expert for the SAP NetWeaver Regional Imple-mentation Group (RIG) EMEA in Walldorf, Germany.

He can be reached at [email protected].

SAP® Education



Page 6 of 24

2 Prerequisites

2.1 Reader understanding

This document is aimed at developers with a basic level of Web Dynpro programming experience.

If this prerequisite has not been met, then the reader will find some, or even all, of this document difficult to understand as it is not the purpose of this document build again the foundational concepts of Web Dynpro programming.

If readers are already familiar with the Model-View-Controller design paradigm, then they must exercise cau-tion insomuch as SAP has implemented a modified and extended version of this design pattern. This in turn has some significant consequences on the architecture of Web Dynpro applications and the way in which they should be coded.

2.2 Installed software

It is assumed that the reader has successfully installed at least the Composition Environment (CE 7.1) Ser-vice Pack 3 version of the SAP Java Server and the accompanying NWDS.

It is not the purpose of this document to describe how to install either the NWDS or the SAP Java Server. The Sneak Preview version of this software can be downloaded from the SAP Service Marketplace.

SAP® Education



Page 7 of 24

3 About this document

3.1 Structure

This document is divided into two parts. The first part (section 4) explains the concept of componentization, and the second (section 5) is an exercise that gives you a step-by-step guide for implementing these princi-ples.

3.2 Graphics and screen shots

A simple principle has been implemented in writing this document – make every pixel count. Therefore, the screen shots shown in this document may have been cropped to eliminate redundant empty space. Only those areas of the screen that carry relevant information have been included in screen shots; so it is entirely possible that the image you see on the printed page is different in size from the corresponding screen seen in the NetWeaver Developer Studio (NWDS).

3.3 Terminology

Certain terms such as “component”, “element”, “context” and “interface” have specific meanings when used in reference to the Web Dynpro for Java toolset. Therefore, to avoid ambiguity, such words will only be used when their Web Dynpro meaning is intended.

SAP® Education



Page 8 of 24

4 Componentization in Web Dynpro Java

The Web Dynpro component is the fundamental building block from which all applications are constructed. The component is both your basic unit of development and reuse.

When you write a Web Dynpro application, you must create at least one component, and applications used to implement real-life business scenarios are frequently constructed from a hierarchy of multiple compo-nents.

4.1 The Web Dynpro Component

A Web Dynpro component is not a single Java class; instead it is an aggregation of independent, yet interre-lated Java classes. No single member of this aggregation can function in isolation from the other members; neither can the member classes be reused individually.

All Web Dynpro components are structured in the same way, yet they can be written to fulfil many different functional roles.

Figure 1: General architecture of a Web Dynpro component

SAP® Education



Page 9 of 24

4.1.1 Component Interfaces

All Web Dynpro components have two types of interface: one is programmatic and the other is visual. It is entirely up to you whether you choose to implement these interfaces; however, from the perspective of re-use, you should implement at least the programmatic interface.

The visual and programmatic interfaces can be seen at the very top of the diagram in Figure 1 on the left and right sides respectively. The interfaces are represented by the circles that extend above the horizontal dot-ted line that marks the boundary between the internal and external parts of the component.

4.1.2 Controllers within a component

Within a Web Dynpro component, there are two general categories of controller. This difference between them is simply determined by whether the controller possesses a visual interface or not. Those controllers that are non-visual are located on the right hand side of the vertical dotted line down the middle of Figure 1. These are the interface controller, the component controller and the custom controller.

The visual controllers are those controllers that span the vertical dotted line in Figure 1. These are the inter-face view controller, the window controller and the view controller.

4.1.3 Why are there two types of controller?

In order for the designers to fulfil the requirement that all Web Dynpro screens should be specified in a client independent manner, it was necessary to modify the traditional MVC concept and create two types of con-troller. The two types of controller that exist in a Web Dynpro component play very different roles: those that are purely programmatic look after the processing of business data, and those that have a visual interface look after the presentation of business data.

Here you can see how SAP has implemented the fundamental concept at the heart of the Model-View-Controller design pattern. Those parts of the component that generate data have been separated from those parts that consume data. The separation of data processing from data presentation is then simply one use case of this more fundamental concept – namely, the separation of data generators from data consumers.

The non-visual controllers are responsible for data generation. The data is then supplied to the visual con-trollers that act only as consumers.

When creating a Web Dynpro component, it is very important that you maintain a clear functional separation between the role of visual and non-visual controllers. If you do not maintain this functional difference, then your component may well be functional, but you will very likely experience all manner of post go-live prob-lems ranging from runtime inefficiency and poor scalability to increased maintenance and enhancement costs.

4.1.4 Models

Notice in Figure 1 that the Model sits outside the scope of the Web Dynpro component. This is because models and components have very different reuse cases, and therefore need to be kept separate.

In Web Dynpro development, all access to backend functionality is performed through a Model object. No matter what communication technology is used to interact with the backend system, all model objects look the same as far as the Web Dynpro component is concerned.

1

1 This is achieved through and interface known as the Common Model Interface or CMI.

SAP® Education



Page 10 of 24

4.2 Dividing Business Functionality into Components

When designing a business application in Web Dynpro, the focus of your attention should (as much as pos-sible) be on implementing the functionality using reusable units of code. These reusable units correspond to your Web Dynpro components. This means that you should consider a component to represent an atomic unit of business processing.

Notice what the focus of your attention is not on: it is not focused on the “Web Page” as it would be in JSP development. Web Dynpro development is focused on components, not web pages.

However, this change of focus leads to the question of how much functionality should you put into a single component. This question has no simple answer, but you should always think about how reusable the result-ing component will be.

As can be seen from Figure 2, component granularity is a balance between two extremes. On the right is the situation in which all the business functionality has been lumped together into a single, monolithic compo-nent. This may well be functional, but it is completely un-reusable. On the left side is the opposite problem. This is what happens if the principles of reusability are taken too far. This produces a large number of com-ponents that in turn, results in complex and fragmented reuse cases. Also at runtime, the Web Dynpro Framework must manage a much higher number of component instances. Spread this across all the users in your system, and you could create heap size problems in the Java engine.

Figure 2: Component granularity is balance between two extremes

4.2.1 Component Hierarchies

Notice that apart from the monolithic component on the right of Figure 2, all the other components are ar-ranged in a hierarchy. This is the pattern all Web Dynpro applications follow. At the top of the hierarchy is a component known as the “Root component”. This component then acts as the central point of control for the activity of the other components further down the hierarchy.

Below the root component, a variety of components types can be found. Which ones are needed depends entirely on the specific details of the required business functionality.

SAP® Education



Page 11 of 24

Figure 3: A component’s reusability varies depending on its position in the hierarchy

4.2.2 Component Types

Technically speaking, there is only one type component in Web Dynpro development: however, it is possible to write Web Dynpro components such that they perform different functional roles. For instance, you can have utility components, model components, visual components or faceless components. The difference between these components lies simply in the role they perform. Figure 3 also shows another component type, intermediate components.

4.2.2.1 Utility Components

A utility component is typically found at, or very near the bottom of a component hierarchy. The reason for this is that these components provide small, frequently used units of functionality. Typically, utility compo-nents will be reused by multiple Web Dynpro applications across an entire suite of business applications.

4.2.2.2 Model Components

A model component is only needed when you need to interact with a BAPI or service in a backend system that has a large or complex interface.

As was stated earlier, all interaction with backend systems takes place via a model object. Where models have a large or complex interface, it would be inefficient to expect every component using this model to re-implement the same logic every time the model object is needed. Therefore, in these situations it makes sense to create a model component that acts as a wrapper around the model object and simplifies the inter-face. Then any other component wishing to make use of this model object can do so by using an instance of the model component.

SAP® Education



Page 12 of 24

4.2.2.3 Visual Components

A visual component is one that defines an abstract screen layout. This type of component typically contains no business functionality, but instead is concerned with taking the visual interfaces provided by other com-ponents and presenting them through its own visualisation layout.

For instance, a visual component could divide the screen up into a toolbar, a navigation area and a content area. Then different child components could be used to supply the actual content seen in these parts of the screen. The advantage with this type of design is that the exact child components that will provide the con-tent to the visual component do not need to be known until runtime, thus allowing for dynamic substitution.

4.2.2.4 Faceless Component

A faceless component is the opposite of a visual component. A faceless component is one that simply has no visual interface. In other words, such a component will never directly present information on the screen. Instead, it will act as a background component that performs some routine task and supplies data to a parent component for visualisation.

Very often utility components will be faceless. This is simply because the tasks they perform are usually related to data creation or manipulation, not data presentation.

Model components are also often faceless, in that they do not present any information directly on the screen during the execution of the business application. However, this does not mean that a model component has no visual interface.

If you need to write a model component, then you are doing so because the interface to a model object is either large or complex (or both). Therefore, the model component will contain the coding that understands the complexity of the interface and presents a greatly simplified version to the outside world.

However, such model components will need to be tested; and also, the business data being accessed could very well need some sort of maintenance or administration. It is in these situations that you would need to write a visual interface for the model component. However, this interface would play no part in the actual business application; instead it would exist only for testing and administrative purposes.

So a component can be said to be “faceless” if it either has no visual interface at all, or its visual interface plays no part in the business application.

4.2.2.5 Intermediate Components

An intermediate component is one that performs a specific role within the scope of a single Web Dynpro application. This type of component brings together the functionality found in its child components in order to implement part of the functionality required by the business process as a whole.

An intermediate component is typically not suitable for reuse because it has been designed to function within the scope of a single business application.

4.2.2.6 Root Component

The root component is the name given to the component at the top of the hierarchy. This component is re-sponsible for delivering the functionality of the entire Web Dynpro business application and cannot be reused individually.

One of the root component’s main tasks is to manage the creation, destruction and interaction of child com-ponent instances. The root component is also the entry point into the business functionality used by all users of the application; therefore, such a component must have a visual interface – in other words, it’s not possi-ble for a root component to be faceless.

SAP® Education



Page 13 of 24

4.3 Component Interface Definitions

If you create a component hierarchy in which the root component has explicitly declared the use of two child components, then you have created what is known as a “tightly coupled” relationship. In object oriented programming, it is quite normal for a parent object to have a tightly coupled relationship with its child objects; however, this type of relationship can introduce a degree of inflexibility to the design that can result in the need to make awkward program changes in future.

Figure 4: The direct declaration of child components introduces a tightly coupled relationship

between the parent and the children

The problem here is that if in Figure 4, you wish to substitute child component A for some other component then you need to alter root component’s declaration of its child – even though all that has changed is the implementation within the child component, not the interface exposed by the child.

Therefore, to overcome the inflexibility of such a tightly coupled relationship, Web Dynpro gives you the abil-ity to create a component interface. The purpose of a component interface is to relax the degree of coupling between the parent component and its children. In doing so, the overall design becomes more flexible be-cause runtime substitution of child components can now be performed.

SAP® Education



Page 14 of 24

Figure 5: The direct declaration of child components introduces a tightly coupled relationship between the parent and the children

Notice in Figure 5 that the root component now only implements the component interface. At design time, it knows nothing about the exact implementation of the interface. All the root component cares about is that the interface remains static. Therefore, any child component that implements this particular component inter-face can be inserted at runtime to provide the required implementation.

Another name for this design technique is polymorphism.

The coding in the root component can now create an instance of any suitable child component in the knowl-edge that the subsequent business functionality will work without needing to be modified.

SAP® Education



Page 15 of 24

Figure 6: At runtime, a suitable component can be instantiated in order to provide the imple-

mentation described by the component interface

The following exercise will show you how to create a simple component hierarchy that makes use of the polymorphic capability of component interfaces.

SAP® Education



Page 16 of 24

5 Working with Component Hierarchies

When one component needs to use the functionality found in another component, then a usage declaration must be made. This immediately creates a parent-child relationship between the two components. To illus-trate this, try the following exercise.

1. In the CE 7.1 version of the NetWeaver Developer Studio, create a Web Dynpro Development Com-ponent (DC) belonging to MyComponents:

a. Vendor : demo.sap.com

b. Name : componentization

c. Caption : Componentization Exercise

d. Language : <your_language>

e. Domain : Basis

f. Support Component : Leave blank2

2. Create a Component Interface called IPerson within the package

com.sap.demo.componentization.cid. Within this interface

a. Create a method called draw() that takes no parameters and returns void.

b. Create a new Interface View Definition called IPersonView and give it an inbound plug

called Refresh.

3. After building the development component, create three new Web Dynpro components within pack-age com.sap.demo.componentization:

a. RootComp with a default window name of RootWindow.

b. ArtistComp that implements the IPerson interface and has a default window name of

ArtistWindow.

c. GunfighterComp that implements the IPerson interface and has a default window name

of GunfighterWindow.

2 The “Support Component” is used internally within SAP for support purposes and is not relevant for customer developed software

SAP® Education



Page 17 of 24

Your Web Dynpro Explorer view should now contain the following entities:

Figure 7: The IPerson interface and the three components

4. Under the Used Web Dynpro Components branch for RootComp, declare a used component usage

called PersonUsage. The actual child component declared for use here will be neither Artist-

Comp nor GunfighterComp; instead we will declare a usage of the IPerson component interface

definition. Give the component usage the name PersonUsage.

Notice that the Lifecycle property is hard coded to “Manual”. This means coding must be manually added in order to instantiate and then call such a child instance.

5. Open the component editor for RootComp by expanding the RootComp branch and double clicking

on the item Component Controller. The Component Editor tab will now open (and depending on your Eclipse settings, a Java Editor may also open – but this is not important at the moment).

6. In the Component Editor, select the Context tab and manually define the following context node:

a. Name: SelectedPerson

b. Collection Cardinality: 1..1

7. Now create a single attribute within this node:

a. Name: Person

b. Datatype: Manually defined as String

8. Save all your open editors by pressing Ctrl-Shift-S

9. Open the Graphical Component Editor for RootComp by double clicking on the component name in

the hierarchy.

10. Pick up the Data Link tool from the graphical editor’s tool bar and drag a connection from the view controller RootCompView to the component controller RootComp. (The direction in which you drag

this connection determines the direction of dependency. Since a view controller should always be written to function as a data consumer and not a data supplier, it is not possible to drag the connec-tion from the component controller to the view controller. If you were able to do this, you would have made the component controller dependent upon data generated by the view controller. This form of dependency is not permitted in Web Dynpro).

SAP® Education



Page 18 of 24

As soon as you lift the mouse button, a popup window will appear in which the context of RootComp

can be seen on the right, and the context of RootCompView seen on the left.

Pick up the SelectedPerson node from the component controller’s context on the right and drop it

on the Root Node in the view controller’s context on the left.

Another pop-up will appear, and in here you can select which attributes of this node will be mapped to the view controller. There is only one attribute to select here!

Close the pop-up windows by first pressing OK and then Finish.

11. In order to get a better idea of the overall architecture, double click on the name of the development component highlighted above in Figure 7 and you will see a graphical representation of the overall relationship between the components and component interface definitions. After some rearrange-ment to improve the clarity, your screen will look similar to Figure 8 below.

Figure 8: The overall relationship between the components and component interface

12. Save all open files with Ctrl-Shift-S and then rebuild the development component.

SAP® Education



Page 19 of 24

13. In the component controller of component RootComp:

a. Add the interface controller of PersonUsage as a required controller of RootComp. Be

careful here: there are two defined usages that could be added. The first is simply a refer-ence to the usage instance, and the second is a reference to the interface controller pro-vided by the usage instance. The simplest option here is to reference both!

b. Create a method called chooseComponent(). This method requires no parameters and

has a return type of void.

c. Add the following coding to method chooseComponent(). This is the manual coding re-

ferred to back in step 4.

public void chooseComponent( ) {

//@@begin chooseComponent()

IWDComponentUsage pUsage = wdThis.wdGetPersonUsageComponentUsage();

// Throw away any child component that might already exist

if (pUsage.hasActiveComponent())

pUsage.deleteComponent();

// Create an instance of the new child component and call its draw() method

pUsage.createComponent(wdContext.currentSelectedPersonElement().getPerson());

wdThis.wdGetPersonUsageInterface().draw();

//@@end

}

Listing 1: Coding for method chooseComponent() in the root component

Notice how no mention is made of either the Gunfighter or the Artist child components? This is because the exact implementation provided by these two child components has been hidden behind IPerson component

interface. All the root component cares about is that the child component can be accessed via this interface irrespective of the exact component instance used at runtime.

14. In the view controller called RootCompView of component RootComp:

a. Create an action called DoButtonChange.

b. In the Java source code for this view controller, locate the method onActionDoButton-

Change() and add a single line of code to call method chooseComponent() in the com-

ponent controller.

public void onActionDoButtonChange(IWDCustomEvent wdEvent )

{

//@@begin onActionDoButtonChange(ServerEvent)

wdThis.wdGetRootCompController().chooseComponent();

//@@end

}

Listing 2: Coding for method onActionDoButtonChange() in the root component’s view controller

c. In the layout editor, change the layout manager property of the RootElement to Matrix-

Layout.

d. Change the text of the default TextView UI element to ‘Both child components implement

the “draw” method’.

SAP® Education



Page 20 of 24

e. Add two radio button UI elements:

i. Name RadioButton1 and RadioButton2

ii. Label “Artist” and “Gunfighter” respectively

iii. selectedKey SelectedPerson.Person

iv. keyToSelect “com.sap.demo.componentization.GunfighterComp” and

“com.sap.demo.componentization.ArtistComp.

If you gave these components package names other than the ones shown previously in step 3, then you will need to use those names instead of the ones shown in this step.

v. onSelect DoButtonChange

f. Add a ViewContainerUIElement called PersonInterface and changes its layoutMan-

ager property to MatrixHeadData.

15. Open the window editor for RootWindow and embed the interface view of PersonUsage into the

ViewContainerUIElement.

Figure 9: The IPerson interface view embedded into the root component view

SAP® Education



Page 21 of 24

The steps performed so far have all been related to the root component. Now we need to prepare the to child components.

16. Download the image files hands.jpg and LuckyLuke.gif from SDN into the respective mimes di-

rectories of your development component. Assuming you have used the recommended names for these objects, the directories will be called (where ${ws} is the name of your workspace)

${ws}.jdi\

LocalDevelopment\

DCs\

demo.sap.com\

componentization\

_comp\

src\

mimes\

Components\

com.sap.demo.componentization.ArtistComp

and

com.sap.demo.componentization.GunfighterComp

17. In the Web Dynpro Explorer view, right click on the development component name and select “Re-load”. The Resources branch in the Web Dynpro Explorer view should now look like this:

Figure 10: The images are located in the Resources branch

18. In the component controller of both ArtistComp and GunfighterComp, manually defined a con-

text node with the following properties:

a. Name: DrawInfo

b. Collection Cardinality 1..1

c. Attribute DrawText, type string.

19. For both ArtistComp and GunfighterComp, do the following:

a. Open the component editor by double clicking on the component name itself

b. Create a data link between the view controller and the component controller.

c. Map the DrawInfo node and its child attribute into the view controller’s context.

SAP® Education



Page 22 of 24

20. Open the Java editor for the component controllers of both ArtistComp and GunfighterComp

and add the following code to the draw() method:

a. For ArtistComp, set the DrawText context attribute to “Get your pencils!”

b. For GunfighterComp, set the DrawText context attribute to “Get your gun!”

public void draw( ) {

//@@begin draw()

wdContext.currentDrawInfoElement().setDrawText("Get your pencils!");

//@@end

}

Listing 3: Coding for method draw() in the component controller of ArtistComp

By the way, how did this method draw() end up here in the ArtistComp component given that you didn’t

declare it explicitly? The answer is that as soon as you said (back in step 3) that ArtistComp and Gun-

fighterComp implemented the IPerson component interface then all the methods found in that interface

were copied into the component controller of the implementing component.

21. Open the view controllers that belong to ArtistComp and GunfighterComp and do the following

for each:

a. Delete the default TextView UI element

b. Change the layout manager of the RootElement to MatrixLayout.

c. Add a new TextView UI element called Description and bind it to the context attribute

DrawInfo.DrawText.

d. Add an Image UI element and change its layoutManager property to MatrixHeadData.

e. Configure the source parameter of each Image UI element to point to the respective mime

image. In the view controller’s layout editor, to the right of the value field for the source

property, there is a “Browse” button from which you can select “Component Image”. As long as you have placed the image file into the correct mimes directory and reloaded the devel-opment component, you will be able to select the image from the pop-up window.

i. Image in ArtistCompView -> hands.jpg

ii. Image in GunfighterCompView -> Gunfighter.jpg

22. Create an application called ComponentizationExercise that uses RootComp as its root com-

ponent.

23. Deploy and run the application.

SAP® Education



Page 23 of 24

Figure 11: The first screen of the demo application

Notice in Figure 11 that neither the Artist nor the Gunfighter component is visible yet. This is because the coding in method chooseComponent() has not executed yet, so no child component instance exists yet.

Figure 12: The two child components are now accessible through the common interface

The resulting application is a simple demonstration of how you can create a component hierarchy in which only the interface is defined at design time. The exact implementation of the child component does not need to be determined until runtime. In other words, this is how you implement polymorphism in Web Dynpro Java.

SAP® Education



Page 24 of 24

In this basic example, the names of the components to be instantiated have been hard-coded into the key-

ToSelect property of the Radio Button UI elements. However, you could just as easily place these compo-

nent names into a local .properties file or even a table in a backend database.

The point here is not so much where the component configuration information is stored, but that a compo-nent hierarchy can be developed in which runtime substitution of child components can be performed. This gives you a much greater degree of design flexibility and simplifies the implementation of future enhance-ments.

Chris Whealy

SAP NetWeaver RIG

March, 2008

Documents

Web Dynpro Java - Archive