ABAP_to_the_Future

12
Web Dynpro ABAP and Floorplan Manager
Using the analogy that views (which live inside windows) in a WDA application
are somewhat similar to their DYNPRO co unterparts (they are not really, as you
will see), you’ll soon see how the co ncepts you know and love in the DYNPRO
world translate into their WDA equivalen ts. First, you’ll learn about the WDA
equivalent to Screen Painter, which is th e good old tool you use to define views
in the classic DYNPRO world. You will berelieved to know there is a WDA equivalent.
Then, you’ll learn about data in a view. In a DYNPRO screen, you work
with global data; because there is no suchthing in a WDA application, you’ll learn
how the data gets to and from the screen. Finally, just as a classic DYNPRO screen
revolves around the PBO/PAI concepts defined in the screen flow, there is a very
similar concept in WDA, and you will also learn about this.
Graphical Screen Painter
You create a DYNPRO screen using a grap hical screen painter. When defining a
WDA view there is still a graphical screen painter (though it has no name; it is just
part of the WDA framework). As with DYNPROs, you have a little box popping
up on the right in which you can change various properties of the screen element
(e.g., right justified, read only, or what have you).
Section 12.2.3 talks about when and how you call this tool. You’ll also see what it
looks like, which is not all that different from what you’re used to.
Storing Data in the Context
In classic DYNPRO, you declare a table area or global variables (usually both) and
then paint fields on the screen with the exact same name; at runtime, the system
automatically copies the values from th e screen field to the identically named
variable in your program. Although it l ooks like the data is only stored in one
place, it isn’t; during processing after us er input, the global variable value might
not change to the screen value until several statements are executed.
Conversely, in WDA it looks like the data is stored in two places; it looks like the
context (a structure containing assorted data fields) in the controller corresponds
to the data in the program, whereas the context in the view is the same structure,
only this time holding the values on the screen that the user sees. In fact, when
you map the two data structures (controller and view) together while creating the
program, at runtime they both refer to the same area of memory—so a change to
one affects the other and vice versa. Ho wever, the controll er must explicitly
512