Web Dynpro Java - Welcome | SCN

SAP® Education SAP Developer Network Web Dynpro

Web Dynpro Java

Creating Your First Web Dynpro Application

Chris Whealy, EMEA Regional Implementation Group

© 2008 SAP AG Creating Your First Web Dynpro Application Chris Whealy

of 43

SAP® Education SAP Developer Network

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 compo-nents 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®, Net-finity®, 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®, Mul-tiWin® 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 in-vented 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 respective companies.

© 2008 SAP AG Creating Your First Web Dynpro Application of 43 Chris Whealy


Content

1 About the Author ..................................................................................7

2 A Brief Introduction to Web Dynpro ...................................................8 2.1 So what is this Web Dynpro thing anyway? ...................................................... 8 2.2 Graphics and screen shots ............................................................................... 8 2.3 Terminology ...................................................................................................... 8 3 Prerequisites.........................................................................................9 3.1 Reader understanding....................................................................................... 9 3.2 Installed software .............................................................................................. 9 4 Building a Web Dynpro Application..................................................10 4.1 Introduction ..................................................................................................... 10 4.2 Basic Design ................................................................................................... 10 5 Structuring a Web Dynpro development ..........................................11 5.1 Overview ......................................................................................................... 11 5.2 Creating a DC of type Web Dynpro................................................................. 12 5.3 Creating a Web Dynpro Component ............................................................... 14 5.4 The Web Dynpro Component Concept ........................................................... 15 5.5 SAP’s implementation of the Model-View-Controller Design Pattern.............. 16 5.6 The structure of a Web Dynpro Component ................................................... 16 5.6.1 Models........................................................................................................ 17 5.6.2 Component Interfaces ................................................................................ 18 5.6.3 Visual and non-visual entities..................................................................... 18 5.6.4 Component Controller ................................................................................ 18 5.6.5 Interface Controller ..................................................................................... 19 5.6.6 Custom Controllers..................................................................................... 19 5.6.7 View Controllers ......................................................................................... 19 5.6.8 Window Controller ...................................................................................... 20 5.6.9 Window Interface Controller ....................................................................... 20 5.7 The Objects within a Web Dynpro DC ............................................................ 21 6 Implementation ...................................................................................22 6.1 Preparing the component controller ................................................................ 22 6.1.1 OK, so what’s a Context?........................................................................... 22 6.1.2 Context structure ........................................................................................ 22 6.1.3 Creating the component controller’s context .............................................. 23 6.2 Preparing the View Controllers ....................................................................... 26 6.2.1 Context Mapping ........................................................................................ 27 6.2.2 Declaring the UI elements .......................................................................... 29 6.2.3 Making the screen interactive..................................................................... 31 6.2.4 So where are we up to? ............................................................................. 36



6.3 Navigating from one screen to another ........................................................... 36 6.3.1 Defining the Window .................................................................................. 37 6.3.2 Creating navigation links ............................................................................ 38 6.3.3 Invoking navigation from the view controllers............................................. 39 6.4 Making your Web Dynpro component executable .......................................... 41 6.5 Deploy and run your application...................................................................... 42



Figures Figure 1: Select Web Dynpro Development Component......................................................................12 Figure 2: Select Web Dynpro Software Component.............................................................................13 Figure 3: Enter the details for the new Development Component ........................................................13 Figure 4: Development Component Editor............................................................................................14 Figure 5: Create a new Web Dynpro Component.................................................................................15 Figure 6: The new Web Dynpro Component ........................................................................................15 Figure 7: The Graphical Web Dynpro Component Editor .....................................................................16 Figure 8: The Architecture of a Web Dynpro Component.....................................................................17 Figure 9: Hierarchical display of a Web Dynpro Component................................................................21 Figure 10: Component Editor - Context ................................................................................................23 Figure 11: Context Menu.......................................................................................................................23 Figure 12: Manual Creation of a Context Node ....................................................................................24 Figure 13: A new (but empty) Context Node.........................................................................................24 Figure 14: Create a “string” context attribute ........................................................................................24 Figure 15: The finished context structure..............................................................................................25 Figure 15: Changing the node’s collection cardinality ..........................................................................25 Figure 16: A default View Controller was created along with the Component......................................26 Figure 17: Rename the view controller .................................................................................................26 Figure 18: Create a second View Controller .........................................................................................26 Figure 19: Rearranging the views in the Component editor .................................................................27 Figure 20: Creating a data link from a View Controller to the Component Controller...........................27 Figure 21: Context mapping..................................................................................................................27 Figure 22: Select which attributes are to be mapped ...........................................................................28 Figure 23: The mapping relationship between the view and component controllers............................28 Figure 24: The completed mapping relationships.................................................................................29 Figure 25: The layout view of the view controller editor........................................................................29 Figure 26: The Outline of the view controller editor ..............................................................................29 Figure 27: Applying the Form template to a view layout.......................................................................30 Figure 28: Select which context attributes will supply data to the form fields.......................................30 Figure 29: The UI elements proposed for the form fields .....................................................................30 Figure 30: The connections between an event on the client and a server side response....................31 Figure 31: Create a new Action ............................................................................................................32 Figure 32: The values of the new Action object ....................................................................................32 Figure 33: The new Action object .........................................................................................................33 Figure 34: Select the Button UI element ...............................................................................................33 Figure 35: The new button UI element starts off in the wrong place and with no text ..........................34 © 2008 SAP AG Creating Your First Web Dynpro Application of 43

Chris Whealy


Figure 36: Change the layoutData and onAction properties of the button UI element .........................34 Figure 37: Completed FirstView............................................................................................................35 Figure 38: Completed SecondView ......................................................................................................35 Figure 39: The default window..............................................................................................................36 Figure 40: The contents of the default window .....................................................................................37 Figure 41: The embed view pop-up ......................................................................................................37 Figure 42: SecondView is now embedded into the window..................................................................38 Figure 43: Two-way navigation between the views in a window ..........................................................39 Figure 44: An action handler method in a view controller.....................................................................39 Figure 45: The code completion feature of the NWDS editor ...............................................................40 Figure 46: Application menu .................................................................................................................41 Figure 47: Create a new application .....................................................................................................41 Figure 48: Create a new application from an existing component........................................................41 Figure 49: Select one of the component’s visual interfaces .................................................................42 Figure 50: Deploy and run the application ............................................................................................42 Figure 51: Enter deploy user id and password .....................................................................................42 Figure 53: Enter your first and last name and then press Next ............................................................43 Figure 54: The second screen echoes the information you entered.....................................................43



1 About the Author Chris Whealy started working with SAP software in 1993 making assembler modifications to the RF and RV modules of R/2. He then went on to work as a Basis consultant installing and upgrading R/3 systems, starting with R/3 version 2.0B.

© 2008 SAP AG Creating Your First Web Dynpro Application of 43

In May 1995, he joined SAP (UK) as a Basis Consultant and ABAP pro-grammer; 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 conse-quently, he taught the first course on this subject in January 1997. Since then, Web-based front ends for SAP functionality 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 be-came the foundation for the book “Inside Web Dynpro for Java” published by SAP PRESS in Novem-ber 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 “Introduc-tion 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 Implementation Group (RIG) EMEA in Walldorf, Germany.

He can be reached at [email protected].

Chris Whealy


2 A Brief Introduction to Web Dynpro

2.1 So what is this Web Dynpro thing anyway?

The simplest way of describing Web Dynpro is to say that it is a toolset for building business applica-tions. SAP delivers three variants of Web Dynpro:

• Web Dynpro for ABAP

• Web Dynpro for Java

• Web Dynpro for Visual Composer1

SAP designed Web Dynpro in order to create a development toolset that would be suitable for the delivery of high quality, robust business applications that can be accessed using a variety of client software products such as standard browsers, Pocket PCs, Blackberrys or Nokia Communicators.

The consequences of SAP’s design requirements have produced a development tool that is built on very simple design principles, yet at the same time, these principles may be unfamiliar to people from a Web development background.

Therefore, it is very important that all developers using Web Dynpro for the first time have a clear understanding of these design principles – otherwise, if you attempt to use Web Dynpro in the same way you have used other Web development toolsets, it is very likely that you will create a large num-ber of support and maintenance problems that will usually not be detected until either the software enters the stress testing phase – or worse still, has gone live.

The purpose of this document is to guide you through the steps needed to create a simple Web Dyn-pro application in Java. In doing so, you will also be introduced to the fundamental concepts of Web Dynpro development.

2.2 Graphics and screen shots

A simple principle has been implemented in writing this document – make every pixel count. There-fore, the screen shots shown 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).

2.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.


1 Web Dynpro for Visual Composer is somewhat different from the other two variants in that you do not have access to modify any coding. Visual Composer is used as the graphical programming tool to create a Web Dynpro implementation of your business application. However at runtime, the application definition is translated from the design time configuration into an executable Web Dynpro application, thus the coding is not accessible for design time modification.

Chris Whealy


3 Prerequisites

3.1 Reader understanding

The purpose of this document is to give someone with no Web Dynpro experience sufficient under-standing to build a basic application. However, there are certain prerequisite concepts with which the reader must already be familiar in order to gain the full benefit from this document.

It is assumed that the reader is already familiar with the following:

• The concepts of Object Orientation

• Java programming

If these prerequisites have not been met, then the reader will find some, or even all, of this document difficult to understand. This document will offer no explanation for above topics.

It is not the purpose of this document to give education in areas that are not specific to SAP devel-oped products. Training materials for the above topics are readily available from bookshops or the Internet, and should be understood prior to looking at this, or any other Web Dynpro document.

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

3.2 Installed software

It is assumed that the reader has successfully installed at least the Composition Environment (CE 7.1) Service 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 Mar-ketplace.



4 Building a Web Dynpro Application

4.1 Introduction

When designing a Web Dynpro application, the programmer must first have a good understanding of the business requirements. This understanding must then be translated into a set of functional re-quirements that can be met by the capabilities of the Web Dynpro toolset.

As a consequence of the fact that Web Dynpro is a declarative programming tool, SAP has deliber-ately shifted the focus of the programmer’s attention away from the low level aspects of coding the user interface (UI) and onto the flow of data through the business process itself.

This shift of attention is made possible by the fact that at design time, the Web Dynpro toolset handles all the mundane aspects of UI programming for you. For instance, if you wish to a have a list of sup-pliers for a particular product displayed in a drop-down list, then all Web Dynpro requires of the pro-grammer is that they place a drop down list UI element on the screen and then declare from where that UI element will get its data. A certain amount of manual coding will of course be necessary to generate the values needed in the drop down list, but beyond that, Web Dynpro will use the design time declarations to generate all the necessary UI and data transport coding for you.

In general, the programmer need only write a comparatively small amount of code to implement those actions that cannot be described in a declarative manner. Such actions would include (amongst other things) calling a Web Service, calling a BAPI in a backend SAP system or implementing a response to a user event on the UI.

4.2 Basic Design

In this introductory example, we will build a Web Dynpro application consisting of two screens. On the first screen, you will enter your first and last names, and these values will then be made available for display on the second screen. There will also be a button on the second screen to return to the first screen.

In creating this simple application, you will be introduced to the following fundamental design con-cepts in Web Dynpro:

• Component based development

• Context Mapping – How to share data between different controllers within one component

• Defining a Web Dynpro user interface

• Data Binding – How to visualise information held within a controller

• How to navigate from one Web Dynpro screen to another

• How to invoke the functionality of a Web Dynpro component from a browser

These concepts are foundational to all further Web Dynpro development, and must be firmly under-stood before moving on to the development of more complex applications.



5 Structuring a Web Dynpro develop-ment

5.1 Overview

In a normal team development environment, SAP recommends that the NetWeaver Developer Infra-structure (NWDI) is installed. This tool will help you manage and administer all aspects of software development. From a Web Dynpro perspective, development is contained within units known as “De-velopment Components”. There are many different types of Development Component (or DC), but the one we are interested in is the DC of type “Web Dynpro”.2 In turn, development components are grouped together into larger units known as “Software Components”. Therefore, before you can cre-ate a development component of any sort, you must first name the software component within which it will live. More details on this topic will be given in a little while.

A Development Component is simply a metadata wrapper used to encapsulate a group of related units of software. Within a DC there is information that describes the following:

• How the software should be compiled (if at all)

• The promotion path through the system landscape

• The public interface of any contained units of software that should be visible outside the scope of the DC (known as “Public Parts”)

• The dependencies this DC may have on the public parts of other DCs.

Many people have asked why development components exist, and the answer is this. A Java class can be referenced for use by any other Java class without requiring direct knowledge that a depend-ency exists. Therefore, if you change a particular class, you cannot be exactly sure how many other classes will be affected by that change. Consequently, large-scale Java developments have been forced to adopt a brute-force approach to software compilation, and recompile the entire application – usually over night.

The whole purpose of the DC concept is to avoid the need for a “nightly build”. This is achieved by the fact that a DC contains a list of both its own public interfaces, and a list of dependencies on the public parts exposed by other DCs. Therefore, when you come to recompile your application, you can be sure that only those parts of the software that were affected by your changes are recompiled.

The consequence of this is that before we can create our Web Dynpro application, we must first cre-ate a DC of type Web Dynpro.3

2 No surprises here I hope!


3 From this point onwards in the document, we will refer to a “DC of type Web Dynpro” as simply a DC. This is because this example uses only this type of development component. It is perfectly possible however, to have different types of DC interacting with each other within the scope of a single Web Dynpro application.

Chris Whealy


5.2 Creating a DC of type Web Dynpro

Having opened the NetWeaver Developer Studio, select the Web Dynpro perspective by following the menu path Window -> Open Perspective -> Other -> Web Dynpro.

Now select File -> New -> Web Dynpro Development Component.

Figure 1: Select Web Dynpro Development Component

If you’re wondering why there is a second option called “Web Dynpro Project”, then this is simply for compatibility with the earliest releases of Web Dynpro.4 Before the NWDI was available for general use, the Web Dynpro Project was used as the container for Web Dynpro development. However, this type of container has the distinct disadvantage that it is a black box. Once software was placed within it, it could not (easily) be reused outside its own scope. This was a serious problem in terms of soft-ware reuse, and SAP strongly recommends that this type of project is never used for productive appli-cations. The Web Dynpro Project should only ever be used if you are writing a throw-away test appli-cation, and support for this entity is likely to be dropped in the future.

The next screen you will see asks for the name of the Software Component to which your (as yet uncreated) Development Component will belong.


4 This option will probably be dropped with the release of Enhancement Pack 1

Chris Whealy


If you are using the NWDS without having a con-nection to the NetWeaver Developer Infrastructure, then you will see only the options shown in Figure 2 above. “Local Developments” is the name of a dummy development track, within which there is a dummy Software Component called “MyCompo-nents”. Press Next to continue.

On the following screen, you need to enter the in-formation about the new DC.

Figure 2: Select Web Dynpro Software Component

Notice that the DC name “firstdc” in the “Name” field does not contain any uppercase letters! Only lower case letters should be used here.

Press Next again and then Finish.

The NWDS now creates the development component and you are presented with an empty canvas area on which to start creating your Web Dynpro components.

Figure 3: Enter the details for the new Development Component



5.3 Creating a Web Dynpro Component

Figure 4: Development Component Editor

Unfortunately, there is a now a clash of terminology. You have just created a Development Compo-nent of type Web Dynpro, but this in itself, is nothing more than a container. In general, DCs do not represent executable units of code, but are rather containers for the transport and compilation of the code they contain. In order for this DC to be of any use, we must now place at least one Web Dynpro Component within it.

As you can see, the word “Component” has been used to mean two different things here.

Do not confuse a Web Dynpro Component with a Development Component of type Web Dynpro: they are two different things!

• A Development Component of type Web Dynpro is simply a metadata container used for the transport and compilation of software.

• A Web Dynpro Component is your fundamental unit of software development and reuse.

The actual functionality for our demo application will be contained with a Web Dynpro Component. As was stated above, a Web Dynpro Component is the fundamental unit of software development and reuse. If you want to write anything in Web Dynpro – even the simplest “Hello World” style application – you must create at least one Web Dynpro Component.

In Figure 4, you can see that “Create Component” tool has been circled. Click on this tool and then click anywhere on the blank canvas area to the right.



Now the pop-up window shown in Figure 5 will appear.

ent.

Enter the name FirstComp and press Next and then Finish completing the creation of your Web Dynpro compon

Figure 5: Create a new Web Dynpro Component

Now, on your Development Component canvas you should see a single Web Dynpro Component called FirstComp.

Figure 6: The new Web Dynpro Component

5.4 The Web Dynpro Component Concept

One area that developers new to Web Dynpro may find somewhat strange at first is the emphasis placed on Components. In Web Dynpro development, it is the Component that is the fundamental unit of software development, rather than a “web page”.

Notice in Figure 6 that the new component has two interfaces. The one shown in light blue on the left represents the component’s visual interface, and the one shown in yellow on the right represents the component’s programmatic interface.

All Web Dynpro development is based on this large scale unit called the component rather than the more familiar small scale units of individual Java classes. This shift of emphasis has many conse-quences when applied to the general principles of Web Dynpro development. We will not go into all those consequences, but I will introduce the most important of these consequences:

A Web Dynpro Component should be written in such a way

that it represents an atomic unit of business processing.

In the case of this little demo, all the functionality can be contained within a single component; there-fore, there is no reason to write multiple components. However, as you become more familiar with Web Dynpro, you will begin to recognise situations where functionality first of all can be encapsulated within a single component, and secondly, how those components can be reused to build up enterprise ready applications from largely pre-written building blocks.



5.5 SAP’s implementation of the Model-View-Controller Design Pattern

Many Web development tools use the Model-View-Controller (MVC) design pattern as the basis for structuring software – and Web Dynpro is no exception here. However, MVC is just a design concept in the same way that Object Orientation is just a concept. The way these concepts are implemented varies from product to product.

The important thing to realise here is that SAP has implemented a modified version of the MVC de-sign pattern; and in doing so, has created a powerful, yet different development tool.

Without specific Web Dynpro training, it is very risky to think that you can start using Web Dynpro as if it were “just like the other Web development tools I’ve used”. Its not!

Some of the biggest implementation problems I have encountered that were faced by customers were due not to Web Dynpro itself, but rather to the fact that the developers were trying to use it as if it were some other product with which they are familiar. The results were functional – insomuch as the software ran without falling over – but it was inefficient, did not scale to the correct user volume, and was very difficult and time-consuming to maintain.

There are two fundamental differences between Web Dynpro and other Web development tools – and one of those differences has already been mentioned – in Web Dynpro, you think in components, not Java classes.

The other fundamental difference is more subtle and takes a little more “getting used to”.

The MVC design pattern is frequently thought of as the pattern that best separates data processing from data presentation – and this is certainly true. However, there is a deeper, more fundamental principle at work here. The separation of data processing from data presentation is just one use case of a more fundamental principle: namely, the separation of data generators from data consumers.

Those parts of the program that, from a business process perspective, perform the role of a data gen-erator are separated from those parts that consume data.

This is a very important concept, and its implications have profound consequences on the way a Web Dynpro component should be designed and written.

5.6 The structure of a Web Dynpro Component

Now double click on the component shown in Figure 6 and you will see part of the internal structure of the component. You have now drilled down into the component and are looking at the controllers that currently exist within it.

Just for the sake for clarity, drag the Window to the location shown in Figure 7. The other entities will automatically rearrange themselves.

Figure 7: The Graphical Web Dynpro Component Editor



What you can see from here is that a Web Dynpro component is not a single Java class; instead, it is a collection of independent, yet inter-related classes that all function together as a single unit. Each controller is an independent Java class, yet they have been written in such a way that they cannot function in isolation from each other. Therefore, from the point of view of reuse, you cannot reuse an individual controller from within a component. You either reuse the whole component as a single unit, or you reuse none of it.

Figure 7 shows only a subset of the entities that could exist within a component. Unfortunately, the layout shown in the graphical editor does not make the role played by each of these entities very clear.

Now compare the diagram in Figure 8. Although this diagram does not represent the layout shown in any of the NWDS graphical editors, it is being used because clearly shows not only the role performed by each entity within the component, but also how those entities interact with each other.

Because the Web Dynpro Component is your fundamental unit of development and reuse, it is vital that you understand the architecture of this unit of software.

Figure 8: The Architecture of a Web Dynpro Component

In Figure 8 you can see that we have expanded on the information shown in Figure 7. This diagram shows you all the possible entities that could exist within a Web Dynpro component.

5.6.1 Models

Notice where Models sit – they are outside the scope of the Web Dynpro component. This is because Models can be reused independently of any specific Web Dynpro component.



A Model encapsulates the interface to some step of the business process located in a backend sys-tem somewhere. This could be a BAPI call, or a Web Service call or an Enterprise Java Bean.

Going back to our data generator/data consumer principle; a Model is always considered to be a generator of data. Some people have become a little confused by this statement because they look at the volume of data that passes into the model and then compare it to the volume of data that is created. Often the Model requires a greater quantity of input data than it generates as output. They therefore conclude that the Model must be a consumer of data because more data travels into it than out.

This is not the correct way to determine whether a Model is a generator or consumer of data.

The Model is always a generator of data because without it, the various steps of the business process could not proceed. The only reason a Model object requires input data, is so that it can complete the next step of the business process. You know whether this step is complete because the Model re-turns some data that indicates either success or failure. It is the data generated by the model that tells you whether that particular step of the business process completed successfully or not.

Therefore, Models are always considered to be generators of data.

5.6.2 Component Interfaces

As has already been mentioned, a Web Dynpro component has two interfaces: one if visual and the other programmatic. You can see that the diagram in Figure 8 has a horizontal dotted line across the top. This divides those parts of the component that are publicly visible (above the line) from those parts that are hidden (below the line).

5.6.3 Visual and non-visual entities

In Figure 8, you will also notice that there is a vertical dotted line. This represents the division be-tween the visual entities on the left and the programmatic entities on the right. What is meant by “vis-ual” and “non-visual” is that visual entities are responsible for data visualization, whereas as non-visual entities are not. Not only are non-visual entities not responsible for data visualization, they are actually incapable of directly presenting data on the user interface.

So you can see that there is a very clear division of labour within a Web Dynpro component. It is very important when developing Web Dynpro components that you do not blur the boundaries between the two types of entity!

From now on, we won’t use the somewhat vague term “entity” anymore; instead, we will start to use the more specific (and correct) terminology.

5.6.4 Component Controller

The Component Controller is a programmatic Java class that is the central point of control for the entire component. As the name implies, this controller is the component itself. The lifespan of the entire Web Dynpro component is exactly equal to the lifespan of this controller.

Notice that this controller lives on the programmatic side of the component. It is not possible for the component controller to place information directly on the screen. That task is delegated to a view controller.

The component controller is responsible however, for generating the data seen by the users on their screens. Therefore, a component controller acts as the middle-man between a model and a view controller. The component controller interacts with the model and obtains data from the backend system. This data may then require pre-processing of some sort before it is ready for presentation. This processing is performed by the component controller and once complete, the data is placed into an area of memory known as the “context”. Each controller within a Web Dynpro component has its



own memory area or “context”, and view controllers can access the information held in the component controller’s context by means of a techniques called “context mapping”.

So in respect of acting as a data generator or a data consumer, the component controller plays a dual role. With respect to a model, the component controller acts as a data consumer.5 However, with respect to a view controller, the component controller acts as a data generator.

5.6.5 Interface Controller

The Interface Controller is where the programmatic interface of your component is defined. Just like a regular Java interface, you can define methods in the interface controller that are then implemented by the component controller.

In addition to being able to define methods in the Interface Controller, you can also define events and data structures (the correct Web Dynpro term for these data structures is Context Nodes).

5.6.6 Custom Controllers

By default, your component will not contain any custom controllers. These controllers are created at design time and can be used to encapsulate any functionality that needs to be shared by multiple controllers within the component.

At runtime, custom controllers are always singletons with respect to the component controller, and are instantiated on demand by the Web Dynpro Framework when they are referenced for the first time.6

Like the component controller, a custom controller will act as a data consumer with respect to a model object (or perhaps even another programmatic controller); but will always act as a data generator with respect to a view controller.

5.6.7 View Controllers

The view controller is the only controller within a Web Dynpro component that can place information directly on the screen. A Web Dynpro component can have zero or more View Controllers.

A view controller can be thought of as an aggregation of UI elements and associated with those UI elements is the coding necessary to perform various data presentation tasks such a basic validation and responding to events in the UI.

A View Controller has a programmatic part (on the right of the vertical dotted line) and a visual part (on the left). The visual part of the view controller is known as its “layout” and it is here that you spec-ify which UI elements this view will display on the screen. These UI elements have various properties that obtain their information from a data storage area known as the context. (Each controller has its own context). This process is called “data binding” and it allows a UI element property to be supplied with information without the coding in the view controller needing to interact directly with the UI ele-ment object. In other words, data binding decouples the coding in the view controller from actual UI element object.

In section 5.5, the data generator/data consumer concept was introduced and it was stated that un-derstanding this concept is of fundamental importance to being able to write high quality Web Dynpro applications. It is very easy to tell how well developers have grasped this concept by looking at the way they write view controllers.

5 Remember that a model is always considered to be a data generator, irrespective of the amount of input data needed to make the model object function.


6 This is an example of a basic principle in Web Dynpro known as lazy data access.

Chris Whealy


A view controller should only ever perform the role of a data consumer – the data is consumed either from some other controller, or from the keyboard and mouse via the user interface.

This means that a view controller is never responsible for generating the data it displays. However, this principle is frequently violated because, from a technical perspective, it is perfectly possible to write coding in a view controller that interacts directly with a model object to obtain data from a backend system. Such coding will function perfectly well, but you will find that code maintenance becomes increasingly difficult because you have violated the principle of separating data generators from data consumers.

The correct division of labour is for a programmatic controller such as the component controller to obtain the data from a backed system via the model object, and then to pass that information to the view controller for display.7 That way you preserve the separation between the data processing layer (the component controller) and the data presentation layer (the view controller).

This may seem like a small and rather pedantic detail: after all, if the coding is functional then the design must be OK?8

NO!

Think bigger than just the effort required to develop the software in the first place, and think about the effort required to maintain the software. 60% to 70% of all software costs are incurred during the application’s maintenance phase. Therefore, spending the time to get the design right at the begin-ning will pay dividends in the long run.

5.6.8 Window Controller

A Web Dynpro Component may have zero or more Window Controllers. Notice that there are arrows pointing from the View Controllers up to the Window Controller. This indicates that in order for any particular view to be visible through the component’s visual interface, it must first have been embed-ded into a Window. Think of the Window Controller as being hierarchically superior to the view con-trollers. Although it would be nonsensical to do so, it is possible to create a Web Dynpro component that has some View Controllers, but has no Window Controller. This would mean the view controllers would never be visible on the screen because they have not been embedded into the Component’s visual interface (implemented by the Window Controller).

In the same way that a view controller handles the processing for an aggregation of UI elements, so a Window Controller handles the processing for an aggregation of views.

5.6.9 Window Interface Controller

In same way that the Component Controller implements the component’s programmatic interface defined in the Interface Controller, so a Window Controller implements the component’s visual inter-face defined in the Interface View Controller.

The Interface View seen within the Interface View Controller is implemented by the Web Dynpro Framework9 and exists only at runtime. The Web Dynpro developer has no direct control over this object.

7 This is achieved through a technique known as “Context Mapping”

8 I’m playing the Devil’s advocate again…


9 The “Web Dynpro Framework” is the name given

Chris Whealy


5.7 The Objects within a Web Dynpro DC

Check that you are still looking at the Web Dynpro perspective in the NWDS (see section 5.2). In the Web Dynpro Explorer view, you can see the hierar-chical structure of the component you have just cre-ated. This view provides an alternate way of navi-gating around not only the constituent parts of a single Web Dynpro component, but all the compo-nents that may exist in this DC.

ed. In the case of our simple example, only a single component is need

Figure 9: Hierarchical display of a Web Dynpro Component



6 Implementation No that we have created both the Web Dynpro component within which your application will live, and the development Component within which it can be compiled and transported,10 we can now focus on the actual implementation.

6.1 Preparing the component controller

As mentioned in section 5.6.4 above, the component controller is the central point of control for all the functionality found within a Web Dynpro component.

In our example we will be asking the user to enter their first and last names on the first screen, and then presenting that information on a second screen.

We now have to think about not only how this information will be stored within the component, but also where?

The answer is, in a place called the context. However, I just stated in section 5.6.4 that each control-ler within a Web Dynpro component has its own context – so which controller’s context should hold this information?

You can find out by answering this question:

Q: Which controller acts as the central point of control for the whole component?

A: The Component Controller.

We also know that the component controller always acts as a supplier of data (or a data generator) for the view controllers within the component; therefore, we know that the component controller is the correct place to store this information.

6.1.1 OK, so what’s a Context?

Irrespective of whether we’re talking about a component controller, a window controller or a view con-troller, they all have their own internal, hierarchical data storage area known as a Context. The Con-text consists of a basic static structure (known as the “root node”), under which the developer can add as many (or as few) nodes and attributes as they require.

As was stated earlier, a component is not a single Java class, but rather an aggregation of independ-ent, yet inter-related classes. Therefore, any data declared to exist within the context of one controller would normally be private to that controller. However, there are certain situations in which the data held within one controller’s context needs to be shared with another controller. This process is called “context mapping”.

6.1.2 Context structure

A context stores information in “attributes”. A set of attributes may be grouped together into a “node” in order to produce a structure that functions much like a database table.11 The only difference be-tween nodes and attributes is that a node may have children, and an attribute may not. From a more

10 Please note that if you place any Web Dynpro developments into the dummy track called “Local Developments”, then transportation of that software around your system landscape is not possible.


11 It is important to understand that a unlike a database table, a context node has no concept of “key fields”. In other words, the context has no concept of data normalization.

Chris Whealy


technical Java programming perspective, a context node can be considered to be a type-safe collec-tion.

Nodes and attributes that have the context root node as their immediate parent are referred to as independent nodes. Conversely, nodes and attributes that have some other node as their immediate parent are referred to as dependent nodes.

This terminology describes whether or not you must write specific coding in your application to instan-tiate such nodes. “Independent nodes” are so named because their existence at runtime is inde-pendent of coding written by the developer. “Dependent nodes” however, require the developer to write specific coding before they will be instantiated.

In our example, the difference between independent and dependent nodes does not feature, but in more complex examples, the difference is important to understand.

6.1.3 Creating the component controller’s context

Double click on the Component Control-ler either in the hierarchical view (under component FirstComp) or in the graphi-cal component editor. Notice that two tabs now open. One called FirstComp and the other called FirstComp.java.


The tab for FirstComp is selected, and you can see the Context. The screen is split into two halves. On the left is the as yet, undefined context for the com-ponent controller, and on the right, is an empty space in which (if suitable decla-rations had been made) the structure of other controller’s contexts could be dis-played.

Figure 10: Component Editor - Context

Figure 11: Context Menu

Right click on the Context root node and select New -> Node as shown in Figure 11.

Chris Whealy


Four options are available:

• Mapping: The node’s structure will be obtained by referencing a corresponding node in a different con-troller.

• Model Binding: The node’s structure will be obtained from a previously created model object

• Structure Binding: The node’s structure will be ob-tained from a previously created structure found in the Java Dictionary

• Manually: The node’s structure will be created by manual definition

Figure 12: Manual Creation of a Context Node

Select the “Manually” radio button and enter PersonInfo into the input field as shown in Figure 12 and then press Finish.

The context will now look like Figure 13. The node has now been created, but it has not attributes. This is of little practi-cal use because it is like creating a da-tabase, but then not defining any col-umns in it!

So the next thing to do is create some attributes within the node in order to store the user’s first and last names.

Figure 13: A new (but empty) Context Node

Right-click on the PersonInfo context node and select New -> Attribute.

The pop-up screen is very similar to the one used for creating a node, except this time, we must give the attribute’s data type which in both cases will be “string”.

Create two attributes for the PersonInfo node. Call them FirstName and LastName respectively.

Figure 14: Create a “string” context attribute



Your context should now look like that shown in Figure 15.

Figure 15: The finished context structure

With the context node PersonInfo still selected (as shown in Figure 15 above), select the prop-erties tab in the lower right quadrant of the screen – not the Properties tab immediately to the left of the “Context” tab shown above.

y one row.

Now change the Collection Cardinality value from the default 0..n to 1..1. This tells the Web Dynpro Framework that at runtime, this context node will contain one, and only one element. This is like saying that a database table can contain onl 12

Figure 16: Changing the node’s collection cardinality

This is all the preparation that is needed for the component controller. Our next task is to prepare the view controllers.


12 Do not think of context nodes being exactly like database table for the simple reason that the context does not implement any concept of data normalisation. Therefore, there is no such thing as a “key field” or a “sort order” in a context node. Context nodes are simply type safe collections of data.

Chris Whealy


6.2 Preparing the View Controllers

When we created the component, we actually skipped over the screen that asked what name you would like to give the default view controller. Therefore, the component creation wizard simply took the component name FirstComp, and bolted the word View onto the end to give FirstCompView.

Figure 17: A default View Controller was created along with the Component

This name is not particularly useful since, the word Comp appears in it, so it should be renamed by right clicking on the view controller name, choosing Refactor -> Re-name, and change the name to FirstView. Of course, it would have been possible

to rename the screen at the time the component was created, but the order of these events is not particularly important.

Figure 18: Rename the view controller

A second view controller is going to be needed to act as the second screen in our application. Therefore, right click on the “Views” node in the Web Dynpro Explorer shown in Figure 17, and select Create View.

After the second view has been created, you will see that two new editor tabs have appeared in the top right area of the NWDS. We don’t need to do anything here quite yet, but these tabs can be left open for the time being.

Double click on the component name FirstComp and you will see the component editor open. This is shown in Figure 20.

Just to make the following concept easier to understand, grab each of the view controllers and drag them to the positions shown in Figure 20 below. If the other controllers automatically reposition themselves, it does not matter because the object of this exercise is to help you understand the concept of how data is shared between different controllers within the same com-ponent.

Figure 19: Create a second View

Controller


of 43


Figure 20: Rearranging the views in the Component editor

Please note the controllers do not need to be in exactly the same positions shown below.

6.2.1 Context Mapping

Now click on the “Create Data Link” tool on the left side of this editor window and drag a line from FirstView to the Component Controller. The purpose of this action is to declare that the View Control-ler will act as a data consumer from the Component Controller.

Figure 21: Creating a data link from a View Controller to the Component Controller

As soon as you let go of the mouse button, a pop-up win-dow will appear that allows you to perform something called Context Mapping.

Since each of the controllers in a Web Dynpro Component is an independent Java class, you would not normally be able to share data between these them. However, the whole concept of a Web Dynpro Component is one in which the different controllers all function together as a single, coherent unit. Therefore, in order for different controllers within the same component to be able to share data, there must be a technique for giving one controller access to the data found in another controller.

This is the purpose of Context mapping.

Click on the PersonInfo node on the right (belonging to the component controller) and drag it across to the left and drop it on the context root node as shown in Figure 22.

Figure 22: Context mapping © 2008 SAP AG Creating Your First Web Dynpro Application of 43

Chris Whealy


Since this node contains two attributes, you are now asked which attributes in the node you want mapped. In this case we want everything, so just click twice on the check box next to PersonInfo, and all the attributes will be selected. Press Fin-ish.

You are now returned to the first context mapping screen where the mapping relationships are dis-played.

Figure 23: Select which attributes are to be mapped

Notice that the arrows in Figure 24 always point from the view controller to the component control-ler – never the other way around. This indicates that the view controller acting as the data con-sumer and the component controller is acting as the data generator.

It is completely impossible for the context map-ping arrows to point in the opposite direction, because this would indicate that the component controller is the data consumer and the view con-troller the data generator. This would completely violate the principles of MVC design, and is there-fore not permitted.

Figure 24: The mapping relationship between the view and component controllers



Press finish, and then repeat exactly the same data mapping process for SecondView.

The component editor should now show two data links between the view controllers and the compo-nent controller, as shown in Figure 25 below.

Figure 25: The completed mapping relationships

Now that the mapping relationships are been declared, each of the view controllers has access to the data held in the context of the component controller. This access is given in such a way that each view controller thinks it is obtaining data from its own local context.

This is an important fact to understand, because when we come to create UI elements in each of the view controllers, those UI elements are only able to obtain their information from the context of the view controller within which they are declared.

6.2.2 Declaring the UI elements

Double click on the FirstView in the component editor, and you will open the view controller editor. There are several tabs across the bottom of the view editor window, and by default, you will see the view’s layout shown in Figure 26.

Figure 26: The layout view of the view controller editor

The “Hello World!” is a default TextView UI element added to all layouts when the view is created. This can be deleted simply by clicking once on the text “Hello World!” and pressing the delete key.

In the bottom left of the screen, there is an Outline View that displays the UI elements as a hierarchy. Once you have deleted the “Hello World!” TextView, all that is left are the root elements for the default UI element container (called the “RootElement”) and the Context Menus.

Figure 27: The Outline of the view controller editor



Right click on the RootElement and select “Apply Template”.

There are ncoul

ow several types of template that d be applied to the view layout. The one we

are after is a form.

Select the Form template and then click Next.

Figure 28: Applying the Form template to a view layout

The next screen asks you which attributes from the context will supply data to the form fields. In this case, click the PersonInfo node and this will cause both the attributes to be selected.

Figure 29: Select which context attributes will supply data to the form fields

The final thing to define is the type of UI ele-ment that should be used to represent each context attribute.

In this case, the default suggestion InputField is perfectly acceptable, so we only need to click on Finish.

Figure 30: The UI elements proposed for the form fields

The layout editor now shows that for each context attribute, a label and input field pair of UI elements have been created.



6.2.3 Making the screen interactive

If we left the screen as it currently stands, the user would be able enter data into each input field, but would never be able to start a round trip to the server. So we need to add a push button to the screen. However, simply adding a push button UI element to the screen will not give the user the ability to start a round trip.

There are numerous UI elements in Web Dynpro that are capable of raising client side events. How-ever, the default behaviour is that there will be no response from the Web Dynpro server when a client side event is raised. Therefore, in order to get the server to respond, we must tell Web Dynpro what to do when a client side event is raised. This is done by creating something called an Action in the view controller. The action is then associated with the particular event raised by the UI element, and it is this association that causes a round trip to take place and invoke some server side processing.

As a result of declaring an Action in the view controller, a corresponding action handler method is created, and it is into this method that you can add the coding that will respond to the client side event.

Figure 31 below shows how the Web Dynpro server responds to a client side event after an Action has been associated with a UI element event. The placeholder ${act} represents the name of any action declared at design time.

Figure 31: The connections between an event on the client and a server side response



Select the Actions tab at the bottom of the view editor, and then press the New button in the top right corner.

Figure 32: Create a new Action

In the pop-up window, give the Action the name of “DataEntered” and a text description of “Next”. Since we will not be passing this action object any parameters, we can immediately press Finish instead of Next.

Notice the way in which the Action has been named. The name of the action corresponds to the event that will trigger it, not the processing that is to take place as a result of the event being triggered. This may seem like a pedantic detail, but it is a good design principle to follow. If actions are al-ways named according to the events that trigger their execu-tion, then it becomes easier to understand the coding during maintenance.

Figure 33: The values of the new Action object



Figure 34: The new Action object

In Figure 34 above, you can see that as a result of declaring an Action, a corresponding Event Han-dler method been created. Figure 31 illustrates the general case in which any Action called ${act} will cause the creation of an associated action handler method called onAction${act}.

The next thing to do therefore is go back to the layout editor, and add a push button. This push but-ton UI element will then be able to raise a client side event that can be associated with the action we have just created.

Select the Layout editor again, and then in the Outline view (see Figure 27), right click on the RootElement and select “Add Child” from the pop-up menu.

The next pop-up window then gives you a selection screen from which the required UI element can be chosen.

Select the “Button” UI element as shown in Figure 35, and then press OK.

Figure 35: Select the Button UI element

Once the button UI element has been added to the screen, you will see the layout shown in Figure 36. Notice that two things need to be changed: firstly, the button is in the wrong place and secondly, it has no text on it.



Figure 36: The new button UI element starts off in the wrong place and with no text

The properties of all UI elements are displayed in the Properties tab in the lower right quadrant of the screen. To move the location of the button, it is necessary to change the UI element’s layoutData property. The default value in this situation is “MatrixData”, but this should be changed to “Matrix-HeadData”. Select the word “MatrixData” shown in Figure 37 and click on the drop down arrow on the far right of the field. Change the value to MatrixHeadData. As soon as this property value is changed, the button will move down and to the left side of the view layout.13

As has been described above, if an event raised by a UI element is not associated with an action, then that event will remain non-functional.

In Figure 37 you can see that the Button UI element is able to raise a single event called onAction. Click in the entry field to the right of this event name and select DataEntered from the drop down list. (If we had not declared the Action first, then this drop down list would remain empty).

This simple declarative action will now cause a round trip to the server when the event is raised, and the action object will then call the associated action event handler method.

Also notice what happens to the button text. Go back and look at the value you entered into the “Text” field in Figure 33. The button text has now inherited the text value belonging to the Action.

Figure 37: Change the layoutData and onAction properties of the button UI element

The view layout will now look like that shown in Figure 38.


13 Giving a UI element’s layoutData property the value of MatrixHeadData, forces that UI element to start of a new row.

Chris Whealy


Figure 38: Completed FirstView

So now the first view is almost ready to run. I say almost because there are a few remaining tasks to perform, but we’ll come back to those in a little while.

Let’s now get the second view prepared. The tasks that must be performed in the second view are pretty much identical to those we have just performed in the first view.

Here’s a list of the things you must do to SecondView:

1. Delete the “Hello World!” TextView UI element

2. Use the template wizard to add a Form using the FirstName and LastName attributes found in the context. After you have selected the context attributes, don’t simply click Finish in the template wizard, instead click Next and change the type of UI element used to display the data from an InputField to a TextView. The fields on the second screen will now be read only.

3. Create an Action object called “Return” and give it a text value of “Back”.

4. Create a Button UI element, position it at the start of a new row by changing the layoutData property to MatrixHeadData and associate the onAction event with the Return action.

SecondView should now look like Figure 39.

Figure 39: Completed SecondView

Now press Ctrl-Shift-S to save all your changes.



6.2.4 So where are we up to?

At the moment, we have a single Web Dynpro component that contains three controllers:

• A non-visual controller called the “Component Controller” (you can’t have a Web Dynpro com-ponent that does not have this controller!)

• Two visual controllers called FirstView and SecondView.

Within the component controller, we have created a context structure in which a person’s first and last name can be stored. These two string values are aggregated together within a context node called PersonInfo.

The two visual controllers (view controllers) also have their own context structures, but these have been created as “mapped” nodes. This means that at runtime, no actual data is stored within the mapped nodes. Instead, the mapped nodes in the view controllers act as references to the actual data stored in the component controller. This ensures that there is only ever one copy of the data, and the view controllers have access to that data by means of a data sharing technique known as “Context Mapping”.

The view controller called FirstView has some input fields into which the user may enter their first and last name. We then want to display that information on the second screen.

We have added some Button UI elements to each view to trigger a round trip to the server, but there is one vital area of configuration that has not been touched yet – screen navigation.

6.3 Navigating from one screen to another

One of the fundamental differences between Web Dynpro and other Web development toolsets is that in Web Dynpro, the basic unit of development is not the web page; it is an entire Web Dynpro compo-nent.

A Web Dynpro component has two interfaces; one is programmatic and the other is visual. Therefore, if you want the user to be able to see anything on the screen, you must configure the component’s visual interface.

At design time, a component’s visual interface is defined by something called a Window. Components can have multiple windows if you wish, but for the sake of simplicity, we will start with a component that has just a single window.

When we created our component, a window was created auto-matically by the component wizard. The default name for such a window is simply the component name followed by the suffix “Window”.

Figure 40 shows the default window in the Web Dynpro Explorer view.

Double click on the window name and the graphical window editor will open.

Figure 40: The default window



6.3.1 Defining the Window

Once you have opened the window editor, you will see the default window definition shown in Figure 41 below.

Figure 41: The contents of the default window

The concept of a window is easiest to understand if you first consider the function of a view controller. A view controller is an aggregation of UI elements (the view layout) plus the associated coding to process user interaction via the client.

As you can see from Figure 41, the window currently has a single view embedded into it (FirstView). This is the default situation after first creating a component (with all the default options).

A window acts as an aggregation of view layouts together with the processing required to manipulate this set of views. So you can think of a window as being hierarchically superior to a view. One view is an aggregation of UI elements, and one window is an aggregation of views.

Now click on the “Embed existing View” tool on the left and then click on the empty space somewhere to the right of FirstView. A pop-up window will appear showing (Figure 42) you a list of all the views in the component, and which ones have already been embedded into the window.

Select SecondView and press Finish.

The view SecondView has now been embedded into the window.

It is important to notice that the two embedded views are shown in different shades of blue. This is not simply for decoration!

The first view embedded into a window naturally becomes the “default” view. This means that when the user sees the screen for the very first time, you do not need to tell Web Dynpro which view to show the user; they will automatically see the default view.

Figure 42: The embed view pop-up



Figure 43: SecondView is now embedded into the window

Notice that SecondView is shown in a lighter shade of blue. This means that this view will never been show to the user unless we explicitly navigate to it.

One thing people new to Web Dynpro sometimes become confused over is how the views embedded into the window relate to what the user sees on the screen at runtime. You could be forgiven for thinking that all the views embedded into the window are somehow visible simultaneously on the screen at runtime. This fortunately is not the case!

In our simple window shown in Figure 43 above, only one of the views will ever be visible at any one time. Which view is visible depends on whether the user is looking at the first screen of the applica-tion. If they are, then the default view (the view shown in darker blue) will be visible. Else, the user could have interacted with the application and caused navigation to take place, in which case, FirstView will be removed from the screen and replaced with SecondView.

However, if we left the window as it stands now, then no navigation would ever take place, and the application would be perpetually stuck displaying FirstView.

So the next thing to do is create the navigation links.

6.3.2 Creating navigation links

At the bottom left corner of Figure 43 you can see there is a “Create Link” tool in the tool bar. Click on this tool and first drag a line from FirstView to SecondView. This will create three things for you:

• An outbound navigation plug in FirstView

• An inbound navigation plug in SecondView

• A navigation link starting from the outbound plug of FirstView and finishing at the inbound plug of SecondView.

That’s fine, but this configuration only allows navigation in one direction. We can now navigate from FirstView to SecondView, but we have not yet defined a return navigation path.

In order to do this, drag another navigation link from SecondView back to FirstView.

You may find that the graphical editor places the inbound and outbound navigation plugs directly on top of each other. If this happens, simply click on the visible plug so that a selection box appears around it, and then slide the plug around the edge of the view to some suitable location.

Your window editor should now look like Figure 44.


Chris Whealy


Figure 44: Two-way navigation between the views in a window

Press Ctrl-Shift-S to save all your changes. This step is very important since it causes the coding to be generated that we will invoke in the next step.

6.3.3 Invoking navigation from the view controllers

Now that we have created the possibility for two-way navigation between our two views, the last thing we need to do is tell Web Dynpro that when the action handler method is called in FirstView in re-sponse to the button push in the client, we need to fire the outbound navigation plug.

This is where we need to write a single line of code in the action handler method in FirstView.

In the Window editor, double click on FirstView and this will open editor tabs. The first shows you the layout of the view controller and the second shows you the Java source code.

Click on tab called FirstView.java and using the Outline window in the bottom left of the screen, locate the method onActionDataEntered().

Figure 45: An action handler method in a view controller

In Figure 45 you can see that there are two special comment markers: //@@begin and //@@end. You are only permitted to place your coding between these comment markers. Be Warned! Any coding placed outside such a pair of tags will be lost when the NWDS regenerates your controller!

Here we need to write the line of code that will invoke the outbound navigation plug.



Create a new line between the two comment markers and enter the following:

wdThis.wd

In itself, this is an incomplete statement, but now press Ctrl-Space and a code completion pop-up will appear like the one shown in Figure 46

Figure 46: The code completion feature of the NWDS editor

The method we need to call is wdFirePlugOut().

Back in section 6.3.2 when we created the navigation links, the outbound and inbound plugs were created for us automatically by the “Create Navigation Link” tool. By default, these plugs will be called “Out” and “In”.

In general, as soon as any outbound plug is created, the NWDS automatically generates a method for you called wdFirePlug${pout}() where ${pout} is the name of the outbound plug.

All you need to do to cause navigation to happen is call this method, and the Web Dynpro Framework handles the rest for you.

Now go to SecondView, locate the onActionReturn() method, and enter the same line of code to cause navigation to occur back to FirstView.

We have now created a complete chain of declarations that allows navigation to take place in re-sponse to user interaction at the client:

• The user clicks on the button UI element

• The button UI element raises a client side event called onAction

• The client side event causes a round trip to the server © 2008 SAP AG Creating Your First Web Dynpro Application of 43

Chris Whealy


• The onAction event has been associated with a runtime action called DataEntered which in turn, causes the onActionDataEntered() method in the view controller to be called

• The onActionDataEntered() method contains a single line of code to fire the outbound navigation plug

• The Web Dynpro Framework then handles all the necessary processing to remove FirstView from the screen and replace it with SecondView.

The same type of processing works when navigating from SecondView back to FirstView.

6.4 Making your Web Dynpro component executable

Everything we have done up till now has been concerned with the functionality within a Web Dynpro component. However, we need some way of allowing a user access to this component’s functionality.

This is achieved by creating something called an Application.

An Application is simply the association of URL with the visual interface of a Web Dynpro component. Once an application has been created, then you have created the means by which a user from a client device (such as a browser) can invoke some Web Dynpro functionality.

The first thing to do is right click on the Applications node in the Web Dynpro Explorer view of the NWDS. From the menu shown in Figure 47, select Create Application.

This will cause the “New Application” wizard to appear as shown in Figure 48.

Figure 47: Application menu

Give the application the name “NameApp” and press next.

Figure 48: Create a new application

We’ve already created the component, so there is no need to change the radio button selection shown in Figure 49, so press Next again.

Figure 49: Create a new application from an existing component



Do you remember that I said it is possible for a Web Dynpro component to have multiple windows? This next screen is present because if you have created multiple windows, then essentially you have given that component multiple visual interfaces. It is here that you would select which visual interface this par-ticular application is to display. However, in our sim-ple case, the component only has one visual inter-face, so there is nothing to select and you can just

ss Finish.

Select one of the component’s visual interfaces

.

Figure 52: Enter deploy user id and password

Once the deployment has finished, your default browser will open and show the first screen of your

pre

Figure 50:

6.5 Deploy and run your application

In order to complete this last step, you must ensure that you have access to a running SAP Java Server. You will need a user id and pass-word in order to deploy applications to the server.

Right click on the name of the application you have just created, and select “Deploy new Archive and Run” from the menu

You will then be presented with a pop-up win-dow in which you must enter the deploy user id and password.

Figure 51: Deploy and run the application

application.




of 43

The first screen will show two input fields ready to accept your information.

Figure 53: Enter your first and last name and then press Next

Once you have entered you first and last name, press next, and the second screen will echo the in-formation you have just entered.

Figure 54: The second screen echoes the information you entered

Congratulations! You have just completed your first Web Dynpro application!

Web Dynpro Java - Welcome | SCN

Documents

Transcript of Web Dynpro Java - Welcome | SCN